Skip to main content
The Komodor Agentic Operation Platform (KAOP) uses the account as its tenancy boundary. Every authenticated request is associated with one account, and every resource the request addresses must belong to that account. Inside the account, each agent has its own identity, permissions, and credential bindings.

​
One request, one account

Authentication establishes both who is acting and which account the identity belongs to. KAOP uses that account context when it reads or changes agents, runs, credentials, knowledge bases, and other resources. Ownership is also carried into the records an agent creates:
  • A run gets its account from the agent being invoked, not from an account value supplied by the caller.
  • Events, evidence, and outputs inherit ownership from their parent run.
  • Resource names are resolved within the account. Two accounts can each have an agent named triage or a credential named github without sharing either resource.
An agent therefore cannot widen its tenancy scope by changing a friendly name or adding an account identifier to a request.

​
Isolation between agents in one account

Sharing an account does not give agents the same access. KAOP evaluates each agent as a separate principal. Granting production access to one agent does not grant it to another. Use Access explorer to inspect an agent’s effective access before you run it against a sensitive environment.

​
Revoking access

Choose the control that matches what you need to stop:
  • Revoke a worker token to prevent that token from authenticating again. This does not stop the worker process itself.
  • Remove a role or grant to prevent future authorization for the affected capabilities.
  • Remove a credential binding to prevent future authorized delivery of that credential.
  • Revoke the credential at its provider when a value may already be loaded in a running process or exposed outside KAOP.
Rotating a worker token requires replacing the deployed token before that worker can authenticate again. Removing a credential binding does not erase a value that a running process has already received.

​
Design checklist

  • Give every agent only the roles and credentials required for its job.
  • Use label-scoped grants to separate teams and environments inside an account.
  • Keep production and non-production credentials separate.
  • Test a representative capability and resource in Access explorer.
  • Revoke credentials at the source as part of incident response.

​
Next steps

Secrets & credential handling

How an authorized credential reaches a worker or run.

Data handling & redaction

What agents can see and what KAOP masks automatically.

Agent identity

How worker tokens establish which agent is acting.

Network & egress control

How deployment choices affect inbound and outbound traffic.