Open any popular agent framework's getting-started guide. Within three steps, you're dropping an API key into an environment variable and handing it to the agent as a tool. One key. Full access. Permanent. The agent can read, write, delete, post, approve — whatever that API allows — for as long as the key is valid. Which is usually forever, because rotating keys is annoying.

That's not a security model. That's a loaded gun left on the counter because the safety switch is technically on.

The security principle that applies here isn't new. It's called the Principle of Least Authority — POLA, sometimes Principle of Least Privilege — and it dates back to 1975. The concept: every component of a system should have access to only the information and resources necessary for its legitimate purpose, and nothing more. Minimum permissions. Scoped to specific data. For the minimum duration required.

Five decades of computer security research. Widely taught. Formally recognized by OWASP (it's section 1 of their AI Agent Security Cheat Sheet — "grant agents the minimum tools required for their specific task"). Required by frameworks like AWS Well-Architected for agentic workflows (GENSEC05-BP01). Demanded by financial services regulators through guidance like the FINOS Agent Authority Least Privilege Framework. And almost universally ignored in practice by anyone actually shipping AI agents.

Why agents break the traditional model

To be fair, applying POLA to AI agents is genuinely harder than applying it to traditional software. Strata.io published analysis last year that gets at why: traditional least privilege assumes access can be designed in advance. You know what the system needs to do, so you grant it the permissions it needs, and that's the end of the conversation.

Agents break this because they decide what to access at runtime. The agent doesn't know at startup what it's going to need. A user sends a message, the agent reasons about what tools to call, and it reaches for permissions in real time. You can't fully enumerate "what does this agent need?" before it runs — that's the whole point.

So most teams shrug and give the agent everything. It's simpler. It works in the demo. And the failure mode — the agent misusing its credentials — feels theoretical until it isn't.

What the failure mode actually looks like

Researchers have demonstrated a class of attack called prompt injection that turns POLA violations into active exploits. Last year, a vulnerability catalogued as CVE-2025-32711 — called EchoLeak — showed what this looks like in practice against Microsoft 365 Copilot. A poisoned email, no user interaction required. Copilot reads the email as part of normal operation. The email contains hidden instructions. Copilot follows them, exfiltrating sensitive business data to an external URL. Zero clicks. The user never sees it happen.

The attacker didn't compromise Copilot. They exploited the fact that the agent had broad email access — read, understand, act — without any structural limit on what it could do with what it found. The attack surface was the agent's own permissions.

This is the mechanism The Hacker News described in January: AI agents are becoming authorization bypass paths. When authorization is evaluated against the agent's identity rather than the human requester's identity, injecting instructions into the agent's context becomes a way to operate with the agent's authority. Which, in most implementations, is substantial.

The agent didn't do something wrong. It did exactly what it was designed to do. The design was the problem.

Microsoft has acknowledged this class of threat. Their security blog committed to rolling out Zero Trust for non-human identities by Q2 2026. The EU AI Act adds compliance pressure — enforcement for high-risk applications starts August 2, 2026, with potential delays for some obligations under the Omnibus package, but August is the binding deadline as of right now. The regulatory and security communities are converging on the same conclusion: agents need scoped, bounded authority, not ambient access.

The zero-credential approach

Most POLA implementations for agents focus on limiting which APIs the agent can call. That's better than nothing. InfoQ published a good breakdown of an agent gateway pattern using MCP and OPA with ephemeral runners — it's close to the right idea.

But there's a stronger version: the agent holds no credentials at all.

Not limited credentials. Not scoped credentials. Zero credentials. The agent is a brain without keys.

When the agent needs to look up an invoice in Business Central, it calls a separate service — a tool container, one per tool — over HTTP. The tool container takes the agent's request, retrieves the caller's credentials from Azure Key Vault per-request, executes the operation, and returns structured data. Credentials exist in memory for one call. They're never written to disk, never present on the agent's container, never accessible to anything the agent might be tricked into doing.

If you compromise the agent completely — full container access — you get nothing useful. No keys. No tokens. No credentials to pivot with. The agent is genuinely empty. Its blast radius is bounded by what it can receive back from the tool containers, not by what credentials it holds.

This is a different claim than "we use least privilege." Most least-privilege implementations still store credentials somewhere accessible to the agent — in environment variables, in a secrets manager the agent can query freely, in a config file. Those are all just access with extra steps. The zero-credential model removes the attack surface by not having it in the first place.

Authorization envelopes for automation

The harder case is autonomous operation. When an agent is running unattended at 3am processing invoices, you can't rely on a human to authorize each step. But you also can't just give the agent everything.

The way to handle this: define an authorization envelope before the task starts. A coordinator agent receives a task — "process today's AP invoices" — and before it does anything, it gets a specific token set: email read (to retrieve the invoices), Business Central entry (to create draft records), Business Central posting (to finalize them). That's the envelope. That's everything the task needs.

The coordinator cannot access accounts receivable. Cannot modify the chart of accounts. Cannot reach payroll. Not because instructions say it shouldn't — because it literally doesn't have the tokens. The restrictions are architectural, not behavioral.

Better: each step uses a different identity. The entry step creates draft invoices using "entry bot" credentials. The posting step finalizes them using "posting bot" credentials. Business Central's audit trail shows two different actors — the same separation of duties a CPA firm requires between a preparer and a reviewer. If the entry token is somehow misused, it can't post. Business Central's own permission system enforces the limit. We didn't write that rule. We just structured the identities correctly and let the ERP do its job.

This is just separation of duties

None of this is conceptually new. Accounting figured it out before computers existed.

The person who writes checks doesn't reconcile the bank statement. The person who creates vendors doesn't approve invoices. The person who approves invoices doesn't cut checks. You don't design this to prevent mistakes — you design it so that fraud requires collusion across multiple people, each of whom has a limited view of the whole picture. Structural impossibility replaces behavioral trust.

When one agent can read untrusted email, reason about it, and act on it with full system credentials — you've collapsed all those roles into one. You've given a single actor complete visibility and complete authority. That's the thing accounting controls exist to prevent.

The FINOS framework for financial services puts it clearly: granular API access, time-bounded permissions, separation of duties. Not because regulators dreamed this up to make your life difficult, but because the underlying threat model — insider misuse, whether by a human or an agent — hasn't changed in 500 years.

The honest counterargument

Yes, this adds latency and complexity. Each tool call includes a vault fetch and an HTTP hop to a separate container. Call it 50 milliseconds of overhead per tool invocation, in the worst case. Some tasks make a lot of tool calls.

The alternative is trusting that the agent won't be tricked into misusing credentials it holds. That the prompt injection researchers don't find a new vector. That the next model version doesn't have an alignment quirk that causes unexpected behavior. That nobody sends a poisoned email to your agent's inbox.

Pick one: 50ms of latency per tool call, or a structurally undefined blast radius when something goes wrong.

I don't think this is actually a close call. Accounting processing isn't latency-sensitive. Nobody cares if invoice entry takes two seconds instead of 1.95 seconds. The alternative — a compromised agent with full API access to your financials — is not a performance optimization you want to make.

· · ·

There's no published work from CPA firms or accounting software vendors specifically on applying POLA to AI agents in accounting contexts. The security research community is working on the agent gateway pattern. The financial services frameworks are emerging. But nobody in the accounting profession has written the accounting version of this yet.

That gap matters. Not because the concept is hard — it isn't — but because the framing has to come from people who understand both the security model and the accounting model. Separation of duties isn't an abstract security principle to an accountant. It's the foundational control that makes financial statements auditable. The accounting mental model maps directly onto the security requirement in a way that "zero trust for non-human identities" doesn't quite capture.

Agents should have minimum permissions, scoped to specific data, for minimum duration. The underlying intuition has been in every accounting textbook since Pacioli. We're just finally applying it to a new kind of actor.