TL;DR: The agent conversation is all about building: which framework, which model, which guardrails. What happens after the agent ships, who manages what it's actually permitted to touch, barely comes up at all. This post breaks down the permission layers underneath every agent and what keeps them governed.
- Building gets all the attention. Managing gets almost none. The industry is full of advice on shipping an agent and nearly silent on running one.
- Three permission layers sit underneath every agent: its own identity, the authority it carries for the person it works for, and its reach into tools and data.
- Agents need their own entitlements. An agent tied to a person should not inherit a copy of that person's access; it needs a separate authorization of its own.
- Static grants don't fit dynamic actors. An agent's task changes by the hour; standing broad access to restricted data means its worst day defines your risk.
- The controls that hold: authenticate every agent, scope access to the task and bound it in time, broker credentials so the agent never holds them, and log every action with its chain of authority.
- The payoff: you can say yes to more agents, faster, because the blast radius of any one of them is bounded.
In our last post on agent discovery, a security leader named the gap in one line: everyone focuses on managing the agents themselves, and almost nobody is thinking about who monitors and governs the permissions underneath them.
If anything, that understates it. The agent conversation isn't even about managing yet. It's about building. Ask how to ship an agent and you'll get frameworks, model comparisons, prompting guides, and evaluation pipelines in overwhelming supply. Ask who manages what that agent can reach once it's running, and the room goes quiet. All of the building advice shapes how the agent behaves. None of it governs what the agent can touch. An agent with a perfect prompt and standing write access to your CRM, your data warehouse, and your email is one bad instruction away from a very efficient incident.
Why isn't building an agent the same as managing it?
Because the permissions question should come up every time the agent acts, and in reality it almost never comes up again after deployment.
Here is how it works now for most organizations. At build time, someone grants the agent the access it needs to work, usually generously, because nothing is more annoying than an agent that fails on permissions. The agent ships, it works, and the builder moves on to the next one. The access stays, untouched, indefinitely. A short term win, and a long term risk. Time-bound and just-in-time access are simply new concepts to most people outside IT and security, and the people building agents now mostly sit outside IT and security. The builder persona has never run an access review or rotated a credential, and no framework tutorial tells them to.
But an agent doesn't do things in general. It does specific things, for specific people, against specific systems, continuously. The question "is this agent allowed to do this right now?" is asked, implicitly, ten thousand times a day. A grant made once at build time answers it ten thousand times with the same yes. Only something sitting in the path of the agent's actions can give a real answer each time.
What is a grant?
A grant is permission for one identity to take one kind of action in one system. “This agent can read the sales database,” “this app can send email on the team’s behalf,” and “this service account can write to the CRM” are each a grant.
This is the same shift we've described as security being the engine of an agentic rollout, not the brake. Teams that can answer the per-action question confidently approve more agents, because any single agent's blast radius is bounded by something stronger than its system prompt.
What are "the permissions underneath" an agent, exactly?
Three layers, and they're governed by different mechanisms, which is why they're easy to lose track of.
The agent's own identity. Every agent authenticates as something: an OAuth app, a service principal, a key. This layer determines what the agent can do standing alone, and it inherits every problem of non-human identity, including the ownership question we covered in the service account post.
Delegated authority, with separate entitlements. Most useful agents act for a person: summarize my inbox, file this ticket, pull this report. The shortcut design hands the agent the person's own session or a copy of their permissions, and it's a trap in both directions. The agent becomes a shadow of its user, holding everything that person can touch whether the task needs it or not, and in the worst case it becomes a privilege-escalation path, where asking the bot returns data your own account would never show you.
The sound design ties the agent's identity to the person it works for while keeping two separate sets of authorization: the person's entitlements and the agent's own. The link makes every action attributable to a human, and the separation means the agent is granted what its mission requires rather than inheriting everything its person can do. This separation of entitlements is the piece most agent deployments skip entirely, and it's the difference between delegation and impersonation.
Tool and data reach. Agents touch the world through tools, increasingly through MCP. Every tool connection is a permission grant, and the agent's real capability is the union of all of them. Two individually reasonable grants can compose into an unreasonable one: read access to customer data plus the ability to send email is an exfiltration capability no one approved as such.
What does managing agent permissions actually look like?
Four properties, enforced in the path of the action rather than in a policy doc.
Every agent authenticates as itself. No shared credentials, no borrowing a human's session. If you can't tell which agent did something, nothing downstream works. This is the foundation of agent SSO and runtime governance: agents get real identities with real sign-in, not API keys taped under the keyboard.
Access is scoped to the task and bounded in time. Instead of standing broad access to restricted data, the agent gets what the current job needs, just in time, and loses it when the job ends. A research agent that needs the data warehouse on Tuesday shouldn't still hold it on Saturday. For builders meeting this idea for the first time: this is normal, it's how mature security teams already treat human privileged access, and it's the single highest-leverage habit to carry into agent work.
The agent never holds the credential. Secrets get brokered at the moment of use rather than embedded in the agent, so a compromised or confused agent has nothing durable to leak. This is the design argument behind credential vending: the application, or agent, does its job without ever possessing the key.
Every action is logged with its chain of authority. Which agent, acting for whom, used which permission, to do what. When something goes wrong, that chain is the difference between an afternoon of investigation and a week of archaeology. For tool access specifically, a gateway in front of MCP gives you one place where all of this is enforced and recorded, instead of a per-integration patchwork.
How does C1.ai manage agent permissions?
C1.ai sits in the path. Agents authenticate through agent SSO with identities tied to the people they work for and entitlements of their own, kept separate from their person's, so delegation never turns into impersonation. Tool access flows through the MCP Gateway where policy is enforced per action, credentials are vended at the moment of use so agents never hold secrets, and every action lands in a record that carries the full chain of authority. Discovery tells you what agents exist. This is the layer that decides what they're allowed to do, every time they do it.
Building agents well gets them running. Managing their permissions is what lets you keep saying yes to the next one.
