Case study · Agent security
The agent boundary: one authorization layer for every agent call
AI agents act on a person's behalf, call tools, and chain steps no one scripted. I product-managed the boundary every agent at Zuora runs through, so what an agent may do is decided by the authorization layer on every call, not by each agent's own code.
- Role
- Product manager
- Company
- Zuora
- Domain
- Agent authorization, least privilege
- Scope
- Every agent call and workflow
- Every
- agent call and workflow passes through the boundary
- 0
- standing privileges for the Organization Admin agent
- 1 action
- to switch an agent off
The problem: agents are a new kind of caller
A person works through a screen that was designed with permissions in mind. An agent reads documentation, decides what to do and calls tools, sometimes across several systems, in sequences nobody scripted. If every team that ships an agent had to solve authorization on its own, controls would vary from agent to agent, and the weakest one would define the risk for the whole product.
Zuora was shipping several agents at once, each for a different job. They needed to share one answer to the question every security team asks first: what is this agent allowed to do?
The design: one boundary for every orchestration
Every agent orchestration at Zuora runs through the agent boundary, which checks the permissions and what the agent is allowed to do before it acts. It covers every agent call and workflow, not a chosen few.
Inside the product, agents work through governed OneID APIs. Outside it, they work through MCP, where OneID is the OAuth authorization server for Zuora's MCP servers, supporting statically registered clients, Client ID Metadata Documents (CIMD) and dynamic client registration. Both paths end up under the same authorization layer.
A person asks
An admin or user makes a request
Agent
Plans the steps and picks tools
Agent boundary
Authorization check
Who is asking, and what is this agent allowed to do? It acts as the requester, with no standing privileges.
Routine
Governed tools
OneID APIs inside, MCP outside
Critical
Human approval
Nothing changes until a person approves
Audit trail
Streamed to the customer's own security tools
The boundary at its strictest: the Organization Admin agent
The Organization Admin agent manages human and AI-agent access across the Zuora suites, which makes it the highest-stakes agent in the product. It shows the boundary at its strictest:
- The agent acts as the admin who asked, with no standing privileges of its own.
- Retrieval is permission-aware, so an answer is grounded only in what the requester is allowed to see.
- Routine requests are handled automatically, assigned by criticality. Critical access is routed to a human for approval.
- Read-only and sandbox modes, plus approve or deny recommendations with a plain-language justification.
- Every action lands in the audit trail and streams to the customer's own security tools.
- A named owner and a one-action deactivation.
Product decisions
Put the check where agents cannot route around it
An agent decides its own next step, so a permission check inside each agent's code is only as strong as that agent's team. Putting the check in one boundary that every orchestration passes through means the rules do not depend on how any single agent was built.
Make autonomy a product decision, not an accident
How much an agent may do alone is scoped deliberately, by how critical the access is. Low-risk work flows. High-risk work waits for a person. The boundary makes that line explicit and adjustable rather than implicit in prompts.
Agents act as someone, not as themselves
The Organization Admin agent borrows the requesting admin's authority for the request and holds nothing in reserve. If the admin could not do it, neither can the agent, and nothing the agent has lingers after the task.
Treat observability as part of authorization
A boundary that cannot be audited cannot be trusted. Actions are recorded and streamed to the customer's monitoring stack, so a security team can see what an agent did as easily as what it was allowed to do.
Where it fits
Authorization decides what an agent may do, and observability shows what it did. The boundary is the first of those.
Read about the production agents →Read the observability case study →Read the OneID case study →Securing AI agents in an enterprise product?
I'm always glad to compare notes on agent permissions, least privilege and keeping a human in the loop where it matters.
Connect on LinkedIn