The AI Agent Permission Problem — and How to Solve It

Your AI agents can now call real APIs. Who decides what they're allowed to do?

For the last two years, the hard part of building with AI was getting the model to do things. That problem is largely solved. Agents now read your databases, file tickets, send emails, move money, and restart production services — autonomously, in a loop, sometimes thousands of times a day.

Which means the hard part is no longer capability. It's control.

The moment an agent can take a real action, you inherit a question no agent framework answers for you: what is this agent actually allowed to do — on whose behalf, under what conditions, right now — and can you prove what it did afterward?

This is the AI agent permission problem. Here's why it's harder than it looks, why the tools you already have don't solve it, and what a real solution looks like.

Why this is different from normal access control

It's tempting to assume IAM already covers this — AWS IAM, Okta, OPA, Casbin. They cover part of it. But the agent trust model adds dimensions traditional access control was never designed for:

1. Delegation. An agent rarely acts as itself; it acts on behalf of a user. If Alice asks her assistant to "clean up my calendar," it should do what Alice can do — and nothing more. Traditional IAM has no native concept of "Agent A, acting for User B, bounded by the intersection of both their permissions."

2. Runtime context. A human's permissions are mostly static; an agent's should depend on the moment — time, IP, environment, dollar amount, the sensitivity of the specific record. "Can read CRM contacts" is too coarse.

3. Non-determinism. A compromised or prompt-injected agent doesn't behave like a buggy script. It improvises and tries tool calls you never anticipated. Your controls must assume the agent itself is untrusted.

4. Auditability for a regulator, not just a developer. When something goes wrong, you need to replay exactly what happened — which agent, which action, which policy matched, who approved it, and proof the record wasn't altered. "We have logs somewhere" doesn't pass a compliance review.

Standard IAM answers "does this principal have permission for this action?" The agent question is richer: "does this agent, acting on behalf of this user, under these conditions, using this tool, have permission at this instant — and is the answer provably recorded?"

Where existing tools fall short

• Agent frameworks (LangChain, CrewAI, AutoGen, MCP) give you tools and orchestration but no opinion on authorization. If the model calls a tool, it runs.
• Policy engines (OPA, Cerbos, Casbin) evaluate a policy against data you hand them — but they're libraries, not control planes. You still build the identities, delegation, approvals, tamper-evident audit, and enforcement yourself.
• Identity providers (Okta, Entra, Auth0) increasingly issue first-class agent identities — useful, but knowing who an agent is doesn't tell you what it may do. The industry now calls that second problem "the authorization gap."

So teams stitch these together by hand — a bit of OPA, a homegrown approval queue, some logging, a brittle "are you sure?" check. It works until it doesn't, and it never produces the audit trail you actually need.

What a control plane for AI agents needs

A real solution isn't a library you wire in — it's a control plane that sits outside the agent's trust boundary and owns five things:

1. A decision API. Before any side effect, ask can I do this? and get back allow, deny, or require_approval — evaluated against subject, action, resource, and live context. Enforcement at the tool boundary means a deny prevents the side effect entirely.
2. Non-escalation by construction. An agent's effective permissions are the intersection of its roles and the dispatching user's roles. It can never acquire more authority than the human who sent it — eliminating privilege-escalation-via-impersonation.
3. Human-in-the-loop as a first-class outcome. When a policy returns require_approval, the agent pauses; a human reviews with full context and approves or rejects. That's the difference between "the AI did something alarming" and "the AI asked, and a human said no."
4. A tamper-evident audit trail. Every decision appended to a hash-chained log (SHA-256 — what the EU AI Act's Article 12 logging effectively requires). Alter a past record and the chain breaks. That's the difference between logs and evidence.
5. Enforcement where agents live. SDK decorators (Python), middleware (TypeScript), callbacks for LangChain/AutoGen/CrewAI — and a gateway in front of MCP servers that authorizes every tool call per-agent.

How Kynara solves it

Kynara is a permission control plane built specifically for AI agents. The core is exactly that decision API:

from kynara_sdk import permission_required

@permission_required("payments.refund.issue", resource_arg="refund_id")
def issue_refund(refund_id: str, amount_cents: int):
    return stripe.refund(refund_id, amount_cents)

If the decision is deny, the decorator raises PermissionDenied before the function body runs — the refund never happens. If it's require_approval, the call pauses and surfaces an approval URL for a human.

Under that one call, Kynara provides the rest of the control plane: RBAC + ABAC evaluated against runtime context; the non-escalation guarantee across the agent→user chain; approval workflows with a review UI and risk scoring; a SHA-256 hash-chained audit log exportable for SOC 2, ISO 27001, and EU AI Act conformance; an MCP authorization gateway that authorizes every tool call per-agent (and hides tools an agent can't use); and identity-provider sync (e.g. Okta) so agent identities flow in from your IdP.

Crucially, Kynara sits outside the model's trust boundary. It evaluates structured requests — not natural language — so a prompt injection can't change what it receives or how it decides. The model can ask for anything; the control plane still says no.

Getting started

You don't have to re-architect. Wrap the handful of tools that actually have consequences — the ones that write data, move money, or touch production — and let everything else through:

1. Register your agents and define a few policies (allow business-hours CRM reads; require approval for refunds; deny blocked regions).
2. Add the decorator/middleware to high-consequence tools, or point your MCP clients at the Kynara gateway.
3. Watch decisions flow into the audit log, and tune from there.

Try the policy logic without writing code in the sandbox, and read the full guide in the docs.

The takeaway

Capability is no longer the bottleneck for AI agents — governance is. The teams that ship agents into real workflows safely won't be the ones with the cleverest prompts. They'll be the ones who can answer, at any moment and with proof: what is this agent allowed to do, on whose behalf, and what did it actually do?

That's the AI agent permission problem. Solving it is what Kynara is for.