Ninety-two percent of organizations agree that governing AI agents is critical to enterprise security. Only 44% have actually implemented any policies to do it. That gap isn't procrastination — it's a structural mismatch between the security models enterprises own and the autonomous systems they're deploying. Agent permission models are where that mismatch becomes measurable, expensive, and dangerous.
Here's the pattern I keep seeing: enterprises are misdiagnosing the AI agent challenge as a pricing problem or a UX problem when it's actually an identity and governance crisis. The companies that treat agents as first-class principals — with native cost tracking, scoped permissions, and lifecycle-managed identities — will avoid the hidden tax of retrofitting legacy seat-based and user-permission models onto autonomous systems. The ones that don't will find out the hard way.
The Principal Mismatch: Why Per-Seat Economics Break for Agents
Per-seat pricing assumes constant marginal cost per user. That assumption held for two decades because software had near-zero marginal cost, every user consumed roughly similar value, and humans did the work. AI agents break all three. Agents have real marginal cost — every interaction burns LLM tokens, tool calls, and compute. One agent can replace ten users. And the agent does the work, not the person billing the seat.
The market is responding. Hybrid pricing has become the default for AI agent licensing, with 41% of AI vendors on a base-plus-usage model in 2026, up from 27% a year earlier. Gartner expects at least 40% of enterprise SaaS spend to sit on usage-, agent-, or outcome-based models by 2030. Meanwhile, per-seat pricing is fading fast for autonomous agents, with 67% of vendors expected to move off it by 2027.
The tension is real. Vendors are racing toward hybrid and outcome pricing to align price with value, but buyers demand predictability and reject consumption models. Salesforce learned this the hard way — Agentforce launched on a $2-per-conversation meter, hit customer resistance, and added a Flex Credits option at roughly $0.10 per action. Same product, repriced because conversation billing was unpredictable.
Outcome-based pricing will fail to scale for a different reason: clean attribution is rare in complex enterprise workflows. Most "resolved tickets" involve ambiguous success criteria, human handoffs, or multi-agent chains where no single action can be definitively credited. Outcome billing becomes a governance bottleneck rather than a pricing solution.
Why Agents Need First-Class Identity — Not Borrowed Credentials
When an AI agent operates without a managed identity and least-privilege role-based access controls, it can access or modify sensitive data beyond intended permissions, and misconfigured permissions may increase potential impact compared to traditional service account scenarios, per Microsoft's security blog. The recommended model is to treat every agent as a first-class principal: give it a lifecycle-managed identity, assign explicit roles, scope its permissions tightly, and bind tool usage to a preconfigured manifest.
This isn't theoretical. The numbers are stark. Systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, and organizations failing to scope AI access properly are 4.5 times more likely to experience a security incident. Despite this, 97% of non-human identities carry excessive privileges, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
The problem compounds when agents inherit permissions through identity platforms. Microsoft Entra agent identities can combine direct app-only permissions with inheritable delegated scopes, including enumerated or allAllowed inheritance, creating a runtime access model that can expand beyond the original assignment if governance is weak. The governance issue isn't the API call itself — it's the assumption that access boundaries stay stable once a blueprint is created.
How Leading Models Handle Agent Identity Differently
Different platforms are solving the agent identity problem in materially different ways. The approaches range from workspace-level agent accounts to dual-principal authorization checks, and the tradeoffs matter for any team evaluating these tools.
| Platform | Identity Model | Key Tradeoff |
|---|---|---|
| Claude Tag | Agent has own account per system; permissions move from per-user to per-channel | Admins must pre-configure workspace-level access; no per-user credential inheritance |
| Genesis Computing | Dual RBAC — both user and agent must independently have access | Adds authorization latency; prevents credential misuse even by authorized users |
| Gravitee 4.12 | Centralized authorization engine evaluates policies at the gateway | Prevents dynamic agents from inheriting broad user permissions; requires gateway deployment |
| Microsoft Agent 365 | Agent-specific permission management; treats agents as non-human principals | Platform-dependent; covers M365 and partner ecosystem agents |
In Claude Tag's agent identity model, the agent has its own account in each system it touches — it posts in Slack as the Claude app, opens pull requests as the Claude GitHub App, and queries your warehouse under a service account provisioned by an admin. Permissions move from per-user to per-channel. This eliminates the "whose credentials apply in a shared channel?" problem, but it means admins must explicitly provision workspace-level access for every tool the agent touches.
Genesis Computing takes a different approach. Their RBAC for agents requires that both users and agents have roles carrying permissions; when a user asks an agent to use a credential, the platform checks that both the user and the agent independently have access. This dual-check model prevents an agent from executing a credential that the requesting user shouldn't be able to access — but it adds a layer of authorization evaluation to every tool call.
Gravitee 4.12 introduces a centralized Authorization Management engine that evaluates authorization policies internally to prevent dynamic AI agents from inheriting broad user permissions and executing unauthorized actions against enterprise data. The engine evaluates policies at the gateway plugin level, eliminating outbound latency for external microservices. This matters because it addresses the nondeterminism problem — agents act dynamically, and a user who can delete a repository shouldn't necessarily delegate that ability to an agent managing their code.
Microsoft Agent 365 provides permission management specific to agent identities rather than treating agents as human user accounts. This matters because 48.9% of organizations deploying AI agents have zero visibility into what they're doing. Agent 365 serves as a control plane to observe, govern, and secure agents across a tenant — not just Microsoft's own Copilot agents, but third-party marketplace agents as well.
The Geodocs Specification: What a Complete Permission Model Looks Like
The Geodocs.dev Agent Permission Model Specification defines roles (agent.reader, agent.editor, agent.admin, agent.billing), OAuth scope mapping, per-tool authorization, consent prompts, time-bound grants, and MCP permission propagation. It requires explicit consent for write tools and any read tool that touches sensitive data.
The spec's core principles are worth understanding because they represent the most complete open permission model I've seen for agents:
- Least privilege. Default deny. Each tool requires an explicit scope.
- Identity per agent. Agents are first-class principals with a stable ID.
- On-behalf-of. Every agent action carries the originating user's principal.
- Time-bound. Grants expire; long-lived tokens are an anti-pattern.
- Human-in-the-loop for risk. Sensitive writes require explicit consent.
- Auditability. Every action is traceable end-to-end.
The identity model has three layers: a service identity for the agent itself, a principal representing the human who delegated the action, and a session identity for a bounded run with its own token and traceable lifetime. Tokens issued to an agent always include claims for all three layers so downstream services can enforce policy on any of them.
This matters because a general OAuth scope like read:all is too coarse for agents that loop over many tools. Without per-tool authorization, a single compromised prompt can exfiltrate data, send messages, or move money. The spec wires OAuth scopes and token exchange into the agent loop so production agents inherit the same controls a human user has. If you're building an agent system, this is the baseline you should be measuring against — and if you're evaluating MCP authorization best practices, you'll find that Enterprise-Managed Authorization covers connection-level access but leaves exactly this kind of per-action runtime authorization to implementers.
The Compliance Cliff: August 2026 Changes Everything
Here's something that should be on your radar if it isn't already. The EU AI Act's Article 50 transparency obligations apply from August 2, 2026, requiring providers to inform users when they are interacting directly with AI agents and to design systems that integrate reliable machine-readable markings into generated content.
The EU Omnibus delayed high-risk AI systems compliance to December 2, 2027 for Annex III systems and August 2, 2028 for Annex I product-integrated systems. But Article 50 didn't move. A transparency breach carries fines up to EUR 15 million or 3% of global turnover. This applies to all companies — including US firms with no EU presence — whose AI is offered to EU users.
On the US side, the proposed Federal AI AGENT Act would require large online platforms to permit authorized AI agents to act on behalf of users while imposing fiduciary-style obligations and technical governance requirements on AI agent providers. The bill is a discussion draft, not law, but it signals where regulation is heading: agents acting on behalf of users will need explicit authorization frameworks, not borrowed credentials.
The Autonomy vs. Blast Radius Tradeoff
Agent autonomy enables multi-step productivity gains and cross-system workflows. Autonomous tool-chaining expands blast radius and requires fine-grained, time-bound permissions that conflict with deployment velocity. You can't have one without the other.
The tradeoff plays out in three dimensions:
Permission scope. Per-agent flat fees offer budget predictability and shift token-cost risk to vendors. Consumption or outcome pricing aligns cost with business value but creates invoice volatility and attribution complexity. The same tension exists in permissions: broad roles speed up deployment but expand blast radius; narrow roles are safer but slow teams down.
Identity inheritance. When agents inherit human access rights, they gain the ability to do everything the human can — including things the human would never delegate. The inherited permissions problem in Entra shows that blueprint-based permissions create reuse and persistence. A single mis-scoped blueprint propagates across every agent that uses it.
Auditability. Rapid agent deployment captures competitive advantage. Retrofitting legacy user-based security creates hidden cost overruns and auditability gaps. When 48.9% of organizations have zero visibility into what their agents are doing, you're not just insecure — you're non-compliant under frameworks that require traceability.
The companies winning here are the ones that build or buy runtime authorization gateways that enforce policy for every agent tool call and deliver required audit trails. The ones losing are still assigning broad service accounts and hoping for the best.
What to Do Before Your Next Agent Deployment
Start with the identity model, not the pricing model. If your agent doesn't have a lifecycle-managed identity with scoped roles and a preconfigured tools manifest, you're accumulating security debt that will cost more than any pricing model you choose. Here's the decision framework:
Inventory your agents. You can't govern what you can't see. If you don't have a registry of every agent operating in your environment — including shadow AI — that's step zero. Microsoft Agent 365 and similar control planes exist precisely because agent sprawl outpaces manual tracking.
Assign first-class identities. Every agent gets its own identity, not a borrowed service account. Permissions are scoped to the agent's role, not inherited from a human user. Time-bound grants are the default, not the exception.
Authorize at the tool level. Connection-level access isn't enough. Every tool call gets evaluated against policy. The Geodocs spec provides the blueprint — roles, scopes, consent prompts, and audit logs wired into the agent loop.
Pick the pricing model that matches your usage pattern. Per-agent flat fees for predictable workloads. Consumption pricing for variable ones. Hybrid for everything in between. But don't let pricing decisions delay identity decisions — the cost of a security incident dwarfs any pricing optimization.
Prepare for August 2, 2026. If your agents interact with EU users, Article 50 transparency obligations are already in effect. If you're waiting for the high-risk deadline extensions, you're looking at the wrong deadline.
The open question I'll leave you with: are you building agent permission models that assume agents are infrastructure — with lifecycle management, scoped access, and audit trails — or are you still treating them as smart API callers that can borrow a human's credentials? The first approach takes more engineering upfront. The second approach is how you become a statistic in next year's security report.
Originally published at SaaS with Alex
Top comments (0)