Agents You Can Trust in Production

Agents get permissions the same way people do. Komodor uses one role-based access model for humans, service accounts and agents. It’s deny-by-default, and grants are scoped to specific resources, patterns or labels. An agent can only touch what its role allows, read or write, environment by environment. The access explorer shows exactly what any identity, human or agent, can actually do.

Docs link: Roles & permissions

Every agent has its own governed identity, separate from the people who use it. Actions are attributed to the agent that performed them, and the record also shows what started the run: a person, a schedule, an alert or a workflow. Agents can’t grant themselves new permissions or impersonate another identity, so accountability holds even when a run was started automatically.

Docs link: Agent identity

Yes. Every run keeps a full evidence trail: its trigger, inputs, tool calls, reasoning, guardrail verdicts, approvals, output and cost. Separately, an append-only audit log records every governed change, such as role, credential, integration and agent changes, plus rejected attempts. The log is written in the same transaction as the change, so a record can’t be skipped.

Docs link: Audit log

Credentials are encrypted at rest and write-only in every management surface. A binding decides which agent may receive each one. A credential reaches only the run that needs it, held in memory and never written to disk or into the run’s evidence. Agents never see secrets in their code, and any delivered secret that appears in output is masked automatically.

Docs link: Credentials & secrets

Yes. Set hourly, daily, weekly or monthly spend caps per agent, and get alerted before a budget runs out. When a cap is hit, Komodor either notifies you or blocks new runs, depending on the action you chose, so a runaway loop can’t turn into a runaway bill. Per-run and per-month cost ceilings can also be required as an organizational standard.

Docs link: Agent spend attribution

Set organization-wide standards once, and every new agent inherits them. Standards cover assigned guardrails, quality evaluation, cost budgets, a named owner and an escalation route. Each agent gets a scorecard against them, and any waived standard is shown on that scorecard, so gaps are visible before an agent runs unattended.

Docs link: Standards & guardrails

All of them. Agents you build on the platform, import from another framework or deploy from Komodor’s catalog are all governed principals. Each one gets roles, an identity and a full run record from its first connection, and uses the same credential, guardrail and budget controls. You don’t maintain a separate policy model for agents that came from elsewhere.

Docs link: Import an existing agent

No. A system prompt is a request, not a control, and instructions inside an agent drift. Komodor enforces guardrails outside the agent, at five boundaries: run start, tool calls out, tool results in, model requests and model responses. Each check returns one of four verdicts: record only, redact, block, or hold for approval. The agent never decides its own consequences.

Docs link: Standards & guardrails

You control that with guardrails. Built-in detectors find data such as payment card numbers, email addresses, private keys and tokens, and redact or block it at the boundaries you configure, before it reaches the model. Credentials delivered to a run are masked automatically. For other personal data, configure redaction rules on the relevant gates and limit what agents can read at the source.

Docs link: Data handling & redaction

Every request is bound to one account, and an agent can only reach resources in that account. Within an account, each agent is a separate principal with its own token, roles, credential bindings and guardrails. Giving one agent production access doesn’t give it to any other agent.

Docs link: Agent isolation & tenancy