AI Agent Security: The Missing Authorization Boundary

Command Palette<br>Search for a command to run...

IIlya Vinokurov

Software architect and open-source builder. I write about AI agents, authorization, distributed systems, and practical software engineering. Currently building Delegent, a capability-based security layer for agentic systems.

Comments (1)<br>Join the discussion<br>KKartik N V J K12d ago<br>p]:my-1 [&>p:first-child]:mt-0 [&>p:last-child]:mb-0">The distinction that auth answers "is the caller allowed" but not "did the human actually intend this" is the gap I keep seeing under-discussed. Willison's lethal trifecta makes it concrete: a fully authorized agent with untrusted input and exfil reach is dangerous precisely because every action passes the permission check. Do you see Macaroons or Biscuit becoming practical for scoping intent per action, or is that still mostly research?

IIlya Vinokurov12d ago<br>p]:my-1 [&>p:first-child]:mt-0 [&>p:last-child]:mb-0">Good question. I think both are practical building blocks today, especially Biscuit for agent workflows. But neither understands human intent by itself. A trusted broker still needs to turn approval into a narrowly scoped token: this action, on this resource, within this time and budget.<br>So I’d say the cryptography is ready; the surrounding product layer is still early. The difficult parts are approval UX, translating intent into exact constraints, revocation, and audit. Macaroons or Biscuit could be part of the solution, but not the whole solution.

Security Boundaries for AI Agents<br>Part 1 of 2

Practical explorations of authorization, delegated authority, human approval, and verifiable audit trails for autonomous software agents.

Up nextDo we really need MCP?<br>I've been calling this approach NoMCP in my notes, in the same kinda spirit as NoSQL. NoSQL never meant "SQL is bad". It meant "not only SQL". Same here.

More from this blog<br>Aug 3, 2026·5 min read

Ilya Vinokurov's blog<br>2 posts

Part of series<br>Security Boundaries for AI Agents

div>p:first-child]:mt-0 [&>div>p:first-child]:pt-0 min-w-0 wrap-break-word [&_a]:break-all **:max-w-full">The Attack Was Authorized: The Missing Security Boundary for AI Agents

Give an AI agent access to GitHub—or to any API or MCP server authenticated with a bearer credential—and the agent receives authority to act in your name.

The credential may not sit inside the model's context. A well-designed system might keep it in the agent runtime, a tool, or a credential broker. But the downstream API sees the same thing: a valid caller making an allowed request. It cannot see whether you intended that particular action.

That distinction matters. If an agent opens the wrong pull request, sends private data to the wrong place, or delegates a task with more authority than you expected, every conventional authorization check may still pass.

The attack was authorized. You just did not authorize the attack.

The service is protecting itself, not you

Simon Willison describes a dangerous combination for tool-using AI as the lethal trifecta: access to private data, exposure to untrusted content, and a way to communicate externally. Put all three in one system and prompt injection can become data exfiltration.

Model-level guardrails help, and we should use them. But I do not think probabilistic detection should be the final authorization boundary. A model cannot always distinguish an instruction from its operator from an instruction hidden in a web page, email, issue, or tool result. Both eventually arrive as input.

The problem is not that GitHub has weak security. GitHub has fine-grained permissions, repository controls, branch protection, short-lived installation tokens, and years of work behind its authorization model. From GitHub's perspective, the agent is simply a valid caller exercising the permissions it was given.

GitHub asks: Is this caller allowed to perform this operation?

It does not ask: Did the human intend this operation as part of the current task?

Nor should GitHub be expected to answer that second question. It does not have the context. The missing boundary belongs between a person and the software acting on that person's behalf.

Machines have always held credentials. Agents are still different.

Service accounts, CI pipelines, and backend applications have used credentials for decades. So it would be wrong to claim that identity systems assume every credential holder is human.

The important difference is behavior.

Traditional automation usually follows code that somebody wrote in advance. It may contain bugs, but its possible actions are relatively predictable. An agent is useful precisely because it chooses the next action at runtime. That choice may be influenced by a user's request, a retrieved document, a web page, another agent, or the output of the previous tool call.

This makes least-privilege design harder. With a CI job, I can usually predict which repository it needs and which operations...