Honestly the least glamorous part of the agent story is the one that actually matters: who's allowed to do what, with whose credentials, and a log of what happened afterwards. Everyone wants to demo the agent opening the pull request. Nobody wants to build the room where you check whether it was allowed to.
The split between caller identity and downstream credentials is the part I wish more agent tutorials started with. When something acts on a user's behalf, collapsing those two layers makes failures hard to debug: you think the agent was allowed to act, but the outbound call used the wrong account. For anything that sends or mutates user data, I treat gateway-held and per-user tokens as different trust zones, and the agent never sees either. How are teams deciding which tools get per-user OAuth versus a shared service principal?
the catalog vs invocation split is sharp. the next hard problem looks like discovery itself, once the toolbox grows past what an agent can hold in context.
The discovery vs invocation split is the part most teams skip. Plenty of MCP servers still treat tools/list as the permission check, then let anything listed execute freely.
Curating the tool surface reads like a security move, but it's really interface design: the model is a user, and a tighter, well-named catalog makes it pick the right tool far more reliably than handing it 200 options.
Makes sense the gateway ended up owning this. MCP launched in November 2024 and only got an authorization framework, based on OAuth 2.1, in its March 2025 spec revision.
The tool catalog matters because execution-time permission checks come after the agent has already chosen an action. I'd scope discovery to the caller, then check the chosen action again before the gateway forwards it. Those two checks answer different questions.
Credential injection is great for agent safety, but it also makes the gateway a high-value target. The article doesn't say how DoorDash reduces blast radius if its own secret store were compromised. Would love to know whether they partition tokens per bundle or rely on short-lived credentials at rest.
The caller-identity vs credentials split is the part most MCP demos skip. Who is asking and what secret to attach are different questions; conflating them is how you end up with a long-lived token sitting in the agent's context.
A gateway that does discovery filtering (tool catalog per agent) plus audit logging also gives you a place to enforce blast radius without rewriting every tool server. Curious how DoorDash handles tool-result size — large log dumps or ticket bodies can blow the context window unless the gateway truncates or pages them.
The section on why identifying the caller is different from supplying credentials is the most underrated part of this. Most agent demos skip it. Once an agent acts for a user, you need to know which human it represents, what the agent may do, and which credentials it can use, and each of those needs its own audit trail. Showing the agent only a selected tool catalog is a smart idea too. It's least privilege, and it also keeps the context window smaller. Nice write-up.
Honestly the least glamorous part of the agent story is the one that actually matters: who's allowed to do what, with whose credentials, and a log of what happened afterwards. Everyone wants to demo the agent opening the pull request. Nobody wants to build the room where you check whether it was allowed to.
The split between caller identity and downstream credentials is the part I wish more agent tutorials started with. When something acts on a user's behalf, collapsing those two layers makes failures hard to debug: you think the agent was allowed to act, but the outbound call used the wrong account. For anything that sends or mutates user data, I treat gateway-held and per-user tokens as different trust zones, and the agent never sees either. How are teams deciding which tools get per-user OAuth versus a shared service principal?
the catalog vs invocation split is sharp. the next hard problem looks like discovery itself, once the toolbox grows past what an agent can hold in context.
The discovery vs invocation split is the part most teams skip. Plenty of MCP servers still treat tools/list as the permission check, then let anything listed execute freely.
Curating the tool surface reads like a security move, but it's really interface design: the model is a user, and a tighter, well-named catalog makes it pick the right tool far more reliably than handing it 200 options.
Makes sense the gateway ended up owning this. MCP launched in November 2024 and only got an authorization framework, based on OAuth 2.1, in its March 2025 spec revision.
AI agents are only as powerful as the tools, permissions and guardrails that connect them to the real world.
The tool catalog matters because execution-time permission checks come after the agent has already chosen an action. I'd scope discovery to the caller, then check the chosen action again before the gateway forwards it. Those two checks answer different questions.
I also wrote a tutorial on this, now at 1k+ GitHub stars: https://github.com/hardness1020/learn-agent-architecture/tree/main/sections/03-permission-sandbox
Credential injection is great for agent safety, but it also makes the gateway a high-value target. The article doesn't say how DoorDash reduces blast radius if its own secret store were compromised. Would love to know whether they partition tokens per bundle or rely on short-lived credentials at rest.
The caller-identity vs credentials split is the part most MCP demos skip. Who is asking and what secret to attach are different questions; conflating them is how you end up with a long-lived token sitting in the agent's context.
A gateway that does discovery filtering (tool catalog per agent) plus audit logging also gives you a place to enforce blast radius without rewriting every tool server. Curious how DoorDash handles tool-result size — large log dumps or ticket bodies can blow the context window unless the gateway truncates or pages them.
The section on why identifying the caller is different from supplying credentials is the most underrated part of this. Most agent demos skip it. Once an agent acts for a user, you need to know which human it represents, what the agent may do, and which credentials it can use, and each of those needs its own audit trail. Showing the agent only a selected tool catalog is a smart idea too. It's least privilege, and it also keeps the context window smaller. Nice write-up.