• Use traces to reconstruct the path, and task context to explain whether each action was permitted.
• Treat delegated authority as a one-way valve: it may stay the same or shrink, but it should never grow without fresh approval.
• Let a model suggest the next step; keep credentials, policy checks, and tool execution under enterprise control.

An employee asks an agent to reconcile an invoice. The agent reads an email, finds a purchase order, checks the finance record, and updates a case. On the surface, the security story looks healthy. Every system sees a valid service identity, and a distributed trace connects the calls.

Then a reviewer asks a harder question: was the case update actually necessary to fulfill the employee's request?

Tracing can show what is called and when. Identity and access management (IAM) can show which identity was permitted to call a tool. Neither tracing or IAM necessarily captures the purpose, limits, and approval that made this particular update acceptable. It is the difference between a receipt that lists every item and an order that explains why those items belonged together. As Srinivasu Bongu wrote in a recent blog post, “Traditional IAM was built for people logging into applications. Agentic IAM has to be built for autonomous software acting on people’s behalf.”

More Agent Activity Means More Authorization Decisions

Traditional automation is usually predictable. A backup service reads a database. A deployment service publishes software. Its identity is a reasonable proxy for its purpose because the path changes rarely.

An agent chooses a path at runtime. The same identity may read a finance record during one task and alter it during another. As agents move from planning to action across enterprise systems, that choice becomes an authorization decision, not just an engineering detail.

This is not an IAM, platform, or application-team failure. Existing controls were built for a different shape of automation. The consequences show up later: slower incident containment, disputed accountability, standing access that outlives a task, and weak evidence during review.

For high-impact actions, a third-party model can suggest a next step, but enterprise-controlled code should hold credentials and decide whether that step fits the approved task. This does not make a model trustworthy. With that boundary in place, it limits the blast radius of a bad suggestion or prompt injection: a read-only task cannot become a write just because the model asks for one.

What Macaroons Got Right

A 2014 macaroons paper described authorization credentials that carry cryptographically protected restrictions, called caveats. The useful idea is simple: authority can be handed off with limits, and someone downstream can make those limits tighter without making them broader.

For the invoice task, the initial authority might name the employee, the business purpose, invoice 123, allowed actions, and an expiry. The next delegation can narrow access to one message, then to a read of one finance record. A case update can require fresh approval.

That is the experiment worth running. Pick one sensitive workflow and write down the task identifier, initiator, purpose, resource, action, expiry, and approval requirement. Test one allowed action, then test a different invoice, a write instead of a read, an expired task, and a broader sub-agent request. The gateway should reject each failure and record why.

Macaroons do not solve the policy problem by themselves. Every receiving service still has to understand and enforce the caveats. That is exactly why they remain relevant. Cryptography can preserve a restriction; only the organization can decide what a legitimate business task permits.

Start Internally, Standardize Externally

An internal pilot does not require waiting for a universal format. It does require restraint: a private token format should not quietly become a cross-company protocol.

The IETF's Transaction Tokens draft is a useful signal. It proposes short-lived, signed context for a specific transaction within a trust domain. A replacement token may narrow allowed actions, but must not expand them. An individual agent extension explores agent identity, originator, hop count, and scope attenuation. It is work in progress, not an endorsed standard.

These drafts can help carry relevant context through systems. They cannot decide whether reconciling an invoice permits a case update or when a person needs to step back in. That policy belongs to the organization.

That leaves a sensible dividing line: define and test the authority boundary inside one trust domain now, then wait for interoperable standards before carrying it across organizational boundaries.

The future may not use macaroons by name. It should preserve their most important rule: delegated authority is a one-way valve. It may stay the same or shrink, but it must never grow without fresh approval.