Agents need a trust layer.

I keep seeing agent demos that feel like magic right up until someone asks, “What permissions does it have?”

Then the room gets quiet.

Fair enough. Nothing ruins the vibe faster than realizing your cheerful little AI assistant can read customer records, open tickets, call APIs, summarize Slack, and possibly expense a panini if the tool schema gets too enthusiastic.

An agent without permissions is a chatbot. An agent with too many permissions is an incident report doing cardio.

That is where the AI community is heading next. Not toward another leaderboard with a name that sounds like a rejected Marvel villain. Toward trust.

Who is the agent? What is it allowed to do? Who approved the action? What data did it touch? Can we revoke access without bringing three systems and one emotionally fragile spreadsheet into the room?

Those are not boring enterprise questions. They are the difference between agentic AI as a useful coworker and agentic AI as a raccoon with OAuth.

Capability got ahead of accountability

The last two years have been about capability. Can the model reason? Can it call tools? Can it write code? Can it plan across steps?

Increasingly, yes.

But capability is not accountability. A model that can decide what to do next can also decide wrong at machine speed. That does not make agents bad. It makes them software.

Software needs boundaries.

OWASP now calls out “Excessive Agency” in its Top 10 for LLM applications, warning that LLM systems become risky when they are given too much autonomy, too many permissions, or access to dangerous tools without proper control. That is the polite security way of saying: please stop handing the intern the production chainsaw.

IBM’s 2025 Cost of a Data Breach report puts the global average cost of a breach at $4.4 million. The same report says 97% of organizations that reported an AI-related security incident lacked proper AI access controls, and 63% lacked AI governance policies. Those numbers should make every agent architecture diagram sweat through its Patagonia vest.

The missing layer sits between intent and action

Most agent stacks are drawn like this:

User gives instruction. Agent reasons. Agent calls tools. Something happens.

That picture is too clean. Real life has procurement systems, production databases, regulated data, vendor APIs, secrets, stale permissions, and Bob from Finance who still has admin access because he “might need it someday.” Bob knows what he did.

A better architecture has a trust layer between intent and action.

That layer answers six questions before an agent does anything meaningful:

• Who is this agent acting as?
• What task was it authorized to perform?
• Which tools may it call?
• What data may it read or change?
• Which actions require human approval?
• What evidence will exist afterward?

This is identity and access management, but with a new actor on the stage. Humans have identities. Services have identities. Workloads have identities. Agents need identities too.

Not vibes. Identities.

“The model decided” is not an audit strategy

There is a sentence I hope disappears from enterprise AI pilots: “The model decided to do that.”

That is not an explanation. That is a shrug wearing a blazer.

If an agent closes a ticket, changes a configuration, sends an email, approves a workflow, or updates a customer record, we need a trail. Not because compliance people enjoy ruining everyone’s afternoon, although they do have suspiciously good stamina. We need it because systems that act on behalf of people have to be inspectable.

The audit log should show the user, the agent identity, the policy evaluated, the tool called, the data accessed, the approval if required, and the final action taken.

That sounds heavy until something breaks.

Then it sounds like oxygen.

Agents need least privilege, not good intentions

The old security rule still applies: give a system the minimum access it needs to do the job.

Agents make this harder because the “job” can be dynamic. A support agent may need to summarize a ticket, search docs, draft a reply, and escalate to engineering. That does not mean it needs permission to refund invoices, delete accounts, or browse the entire customer database like it is wandering through Costco on a Saturday.

Good agent design should feel a little annoying. Narrow scopes. Short-lived credentials. Tool-level permissions. Human checkpoints for irreversible actions. Clear revocation. Logs that someone can actually read without entering a fugue state.

A little friction is not failure. It is steering.

Trust is the product feature nobody screenshots

The AI community loves a good demo. I do too. Watching an agent turn a vague request into working code is delightful, especially while the rest of us sip coffee and pretend we knew it would work.

But demos hide the hard part. Production exposes it.

In production, the question is not “Can the agent do the thing?” The question is “Can the agent do the right thing, within the right boundaries, with the right evidence, repeatedly, when nobody is watching the demo tab?”

That is the trust layer.

The next serious agent platforms will compete on trust as much as intelligence. Identity, authorization, policy, observability, and auditability will become core architecture, not the appendix someone adds after the pilot gets uncomfortable.

Agents are actors in digital systems.

And every actor needs a badge, a boundary, and someone checking the receipts.

Sources

• OWASP Top 10 for LLM Applications, including “Excessive Agency.”
• IBM 2025 Cost of a Data Breach Report.
• Verizon 2026 Data Breach Investigations Report page, for breach-pattern context around human factors, credentials, vulnerabilities, and ransomware.