Authorize The Action, Not Just The Agent
Ganesh Kirti is Founder and CEO of TrustLogix, which builds runtime authorization for AI agents, data, and applications.
gettyI’ve been building authorization systems long enough to remember when the hard part was getting single sign-on to work across three apps. The model back then was simple, and honestly, pretty good. It was a classic three-tier application: The user logged in at the front end, the middle tier checked a role, and the database trusted the app’s service account. It worked because people wrote and reviewed the code, and every query existed for a reason someone had decided on in advance. Identity was effectively a proxy for permission.
Agents don’t respect any of that. A planner decides at runtime which tools, subagents and APIs to use. Some agents work for a person, and many run on their own, under a business process some manager owns. By the time the request reaches the database, it’s usually one shared service account. Who asked for this? Why? Gone.
Gartner expects that by 2028, a quarter of enterprise security breaches will trace back to AI agent abuse. Having watched how agents actually get rolled out, I believe it. Identity teams know who the agent is, and data teams know what the data is and what it’s allowed for. But they sit in different orgs and write policy in different languages. The agent needs both answers at the same time, every time, but almost nobody puts them in the same decision.
The unit is the action: a tool call, a query, one agent handing work to another. Each is a small transaction that deserves its own decision. Who or what kicked it off, and on whose authority? What’s the job? What is the data cleared for? How much do we trust this agent right now? The answer is often a variation of “yes, but.” Yes, but only your region’s dataset rows. Yes, but account numbers come back masked. Read it, sure. Export it? No.
Don’t let the agent tell you its intent. Every action needs an intent, but if you take the agent’s word for it, you’ve already lost. A prompt-injected agent will tell you, very politely, that it’s doing fraud review. Instead, pull intent from things the agent can’t rewrite: the request or business event that started the work, the workflow step it’s on. Then turn that into structured claims the policy engine checks the same way every time. A model can help read a messy request, but it shouldn’t make the call.
Let what the data means drive the policy. Agents ask for data by meaning (“show me at-risk customers in Texas”), not by table name, so policy has to understand meaning too. Data teams already write much of this down, including owner, classification and approved uses. If the contract says “fraud detection: yes,” but “marketing: no,” that belongs in the access decision. The same goes for sovereignty, entitlements, legal entity and reporting line.
Generate least-privilege policy instead of hand-writing it. Hand-writing policy for a few dozen agents is doable, but not for thousands. First, find out what you have. Inventory agents across platforms and figure out who owns each one and what it’s for. Map the datasets and MCP tools it can reach. Then generate a starting policy from the mission, the data’s classification and allowed purpose, and what the agent really does day to day.
At the data layer, that means row filters and column masks that fit the mission. At the tool layer, the agent sees only the tools its job needs. Read stays separate from write, and parameters get limits (row counts, destinations). Write policy per mission type, not per agent, or you’ll drown. Start in monitor-only mode, with owners approving or tightening by exception. Keep comparing granted against used, because they drift apart fast.
Decide in one place, enforce wherever the agent goes. Agents come in through API gateways, AI gateways, MCP servers and agent frameworks, sometimes straight into the data platform. If each makes its own call, you get five policies that disagree. Keep one decision authority and enforce it at every point. Push decisions into the data platform’s native controls where you can, so no proxy sits in the data path. The OpenID Foundation’s Authorization API 1.0, finalized in January, standardizes how enforcement points ask for decisions, and that removes a lot of integration pain.
Build a kill switch that actually kills. Ending a session doesn’t stop an agent; it just opens a new one. Revoke the grant, so the next request fails on every connected system, without redeploying policy. It doesn’t have to be all or nothing. Narrow a tool or mask a column first, and pull the plug if that isn’t enough. Watch behavior against declared mission so you know when to step in, and time your revocation; if you’ve never measured it, it’s probably slower than you think.
Start with one workflow that matters and touches regulated data. Identify the agents involved, generate policies for them and run in monitor-only mode for a few weeks. Along the way, measure three things: how long authorization decisions take, what share of agents are running under generated least-privilege policies, and how quickly you can shut down a single agent across every system it touches.
Identity is where authorization starts, just not where it ends anymore. With agents, the question has moved from who you are to what you’re doing, and whether the data you’re about to touch was ever meant for that. You answer that at runtime, at the moment of the action, every single time.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
