> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How it works

> The five things that decide what an agent may do — identity, permissions, standards, runtime guardrails, and the record of every decision.

Letting an agent act on production is a governance problem before it is a technical one.
The Komodor Agentic Operation Platform (KAOP) answers it in five layers: every actor has an
identity, every identity holds permissions, every new agent inherits your standards, every action
crosses a gate that can refuse it, and everything consequential is recorded. This page explains how those layers fit
together, so the pages under it read as one system rather than five features.

## The five layers

<CardGroup cols={2}>
  <Card title="Identity" href="/security-and-governance/identity-and-access/signing-in">
    People, service accounts, and agents are all first-class principals in a workspace. Nothing acts
    anonymously.
  </Card>

  <Card title="Permissions" href="/security-and-governance/identity-and-access/roles-permissions">
    Roles and grants decide which capabilities an identity holds, and on which resources. Default
    deny, additive grants.
  </Card>

  <Card title="Standards" href="/security-and-governance/controls/standards-guardrails">
    Every agent is created against your organization's standards — ownership, budget, judges,
    guardrails — with waivers shown rather than hidden.
  </Card>

  <Card title="Runtime gates" href="/security-and-governance/controls/standards-guardrails">
    Guardrails inspect a tool call, a model request, and what comes back, and can refuse or redact
    before the action lands.
  </Card>

  <Card title="Approvals" href="/security-and-governance/controls/approvals">
    A consequential action can wait for a person, with the evidence needed to decide.
  </Card>

  <Card title="The record" href="/security-and-governance/controls/audit-log">
    Every governed change and every sensitive read is written to an append-only audit log.
  </Card>
</CardGroup>

## The principle underneath

**An agent is governed the same way a person is, and by the same machinery.** An agent has its own
identity, holds its own roles, and is refused by the same enforcement that refuses a human — which
is what makes "what can this agent do?" a question with an answer rather than an assumption.

Two properties follow from that, and they are worth stating because they are what makes the model
trustworthy:

* **Enforcement is not inside the agent.** An agent cannot decide to skip a check, because the checks
  do not run in the agent's process. They run at the boundary the agent's traffic has to cross.
* **The identity is the credential.** A worker's token resolves the agent and its workspace on its
  own. An agent cannot present someone else's name and be believed.

## What each layer stops

| Layer       | The question it answers                   | What it stops                                               |
| ----------- | ----------------------------------------- | ----------------------------------------------------------- |
| Identity    | Who is acting?                            | An action nobody is accountable for                         |
| Permissions | Are they allowed to act on this resource? | An identity reaching beyond its job                         |
| Standards   | Was this agent built to our rules?        | A new agent shipping without an owner, a budget, or grading |
| Guardrails  | May *this* action proceed, right now?     | A permitted capability being used destructively             |
| Approvals   | Should a person decide instead?           | An irreversible action taken without a human                |
| Audit log   | What happened, and who did it?            | A change nobody can reconstruct                             |

## Reading order

Start with [Signing in](/security-and-governance/identity-and-access/signing-in) and
[Roles & permissions](/security-and-governance/identity-and-access/roles-permissions) — they
establish the vocabulary every other page uses. Then read
[Standards & Guardrails](/security-and-governance/controls/standards-guardrails) for the controls
that act at runtime, and the Architecture considerations section for how workspaces, secrets, data,
and network traffic are isolated underneath.

## Next steps

<CardGroup cols={2}>
  <Card title="Agent identity" href="/security-and-governance/identity-and-access/agent-identity">
    How an agent authenticates and what it is permitted to do.
  </Card>

  <Card title="Access explorer" href="/security-and-governance/identity-and-access/access-explorer">
    Check what an identity can actually do, before you change anything.
  </Card>

  <Card title="Agent isolation & tenancy" href="/security-and-governance/architecture-considerations/agent-isolation-tenancy">
    The workspace boundary, and how it is kept.
  </Card>

  <Card title="Secrets & credential handling" href="/security-and-governance/architecture-considerations/secrets-credential-handling">
    How a secret reaches a run without being exposed.
  </Card>
</CardGroup>


## Related topics

- [How it works](/manage-your-agents/build/how-it-works.md)
- [Optimize — how it works](/manage-your-agents/optimize/how-it-works.md)
- [Architecture](/get-started/architecture.md)
- [Orchestration](/manage-your-agents/run/orchestration.md)
- [Grafana Investigator](/manage-your-agents/build/catalog/grafana-investigator.md)