AI agent authorization

AI agent authorization decides which actions an AI agent may perform, against which resources, under the authority its organization assigned to it. It is a decision made about a specific action, at the moment that action is attempted.

Why the question changed

For most of software's history, the thing you authenticated produced output. It answered, calculated, rendered, returned. If it was wrong, you read something wrong.

An AI agent does not stop at output. It opens pull requests, deploys, writes to databases, moves records, sends messages. It changes real state in systems other people depend on.

To do any of that it holds a credential, and that credential is constant. It does not change between one request and the next. The consequence of each request changes enormously.

Same agent. Same credential. Same connection. The credential was checked once, when the connection opened, and it answered one question: who is calling. Every one of these actions was requested later, by that same authenticated caller.

So there is a question the credential cannot answer, not because it is weak but because of when it was checked: is this particular action, right now, inside what this agent was actually granted? That question can only be answered per action, at the moment the action is attempted, and before it runs.

Identity is not authority

That is the distinction. Identity establishes who is acting. Authority establishes what that actor may do right now. An agent can authenticate correctly and still request something far outside what it was granted; the credential proves who is asking, and says nothing about whether this particular action is inside the policy assigned to that agent.

Identity infrastructure is not the problem here, and none of it becomes unnecessary. OAuth, IAM, service accounts and workload identity establish who or what has access. Authorization at the action level answers the narrower question that access alone does not answer.

Authentication, access, authority

These are related and often conflated. Keeping them separate is most of the work.

Authentication

Establishes who or what is acting.

Access

Establishes that an actor can reach a system at all.

Authority

The bounded set of actions an operator delegated to an agent, under a policy the organization authors.

Policy

The authored, versioned statement of what an agent may do. When rules overlap the most restrictive matching outcome wins, and the safe default is reject.

Approval

A held action, resolved by a human, for cases policy routes to a person rather than deciding outright.

Revocation

Withdrawing authority. It governs future actions only. It never reverses an action that already executed.

Execution

What the underlying tool or system does once an action is permitted to proceed. A separate fact from the decision.

What happens before a governed action

A governed action is one that passes through an authorization boundary you configured: the resources you enroll and the policy you assign, for supported action types. What does not pass through that boundary is not governed. This is a boundary you configure, not a claim of universal control over the host.

When a governed action is attempted, it carries a verifiable reference to its authority, and that authority is checked before the action runs. The check returns one of three decisions: ALLOW, and the governed action proceeds; REJECT, and it does not; APPROVAL REQUIRED, where the action is held, the prompt renders in the agent's own harness, and it resolves to ALLOW or REJECT.

Authority can change without the agent changing. A policy edit or a revocation changes what the same agent may do next, while its identity stays exactly the same.

ALLOW is not proof the action succeeded

An ALLOW decision means the authority boundary permitted the attempt. It does not mean the underlying tool succeeded. An allowed action can still fail at the provider, and the authorization decision and the execution outcome are recorded as distinct evidence. Conflating the two is how audit systems become misleading.

Keydris does not execute the underlying action. The tool or system that receives the action owns execution and its outcome.

What Keydris does, and does not

Keydris is action-time authorization for AI agents. You assign an agent bounded authority in a policy; when a governed action is attempted, Keydris decides whether it may proceed, and records the decision with the policy version that produced it.

The boundary is not only a yes or no. The agent never receives the connected credential: the keys and secrets an action requires are held apart from it and released only for an action that has already passed policy. Rules are versioned, the most restrictive matching outcome wins, and the default is reject, so an action nobody wrote a rule for does not slip through.

Keydris does not:

• run the model, or read or control the model's intent.
• execute the underlying action, or guarantee that an allowed one succeeds at the provider.
• issue or replace your identity system.
• become your MCP server.
• reverse an action that already executed.

How this relates to OAuth, IAM and MCP

Keydris complements the stack you already run. OAuth, gateways and policy engines stay where they are. OAuth, IAM, service accounts and workload identity establish who or what has access; Keydris works alongside them and adds a per-action authority check: whether this specific governed action is inside the policy assigned to this agent right now.

MCP has authorization, and it matters. Keydris governs actions that reach a boundary you configured: a broker on your side, a KIT Reader on the receiving MCP server, or an integration where a Reader cannot be installed. None of these replace the protocol's own authorization; they add the authority decision around a governed action.

What exists today

Keydris is early, and availability is Developer Preview. What is described above is the current shape of the product: policy-defined authority, a verifiable reference to it on a governed action, an authority decision at the boundary, approval and revocation, and a record of each decision with the policy version that produced it. Production use is possible; there is no production SLA yet.

No path completes the authority decision without the Keydris platform today, and where the decision cannot be reached the boundary fails closed: the action does not proceed.

What is direction, not product

The founder thesis argues a longer arc than the product currently implements. Portable authority across organizations, an authority graph describing everything an organization's machines may do, and neutral authority infrastructure between companies are stated there as direction, not as current capability. They are not available today, and nothing above depends on them.

Where to go next

The fastest way to see this is to run it: install, assign a policy, perform an allowed action and a rejected one, and read why each got its decision.