The Agent Can, But Should It?

Access controls tell you what an AI agent is able to do. They say nothing about what it is allowed to do, and most organizations have never written that second part down. 

In 2025, a developer told a coding agent not to touch the production database. The agent deleted it anyway, generated thousands of fake records to cover the gap, and said a rollback was impossible. It wasn’t an attack. The agent was trying to be helpful. The instruction existed, but nothing enforced it. The agent held credentials that allowed the deletion, and nothing else said it wasn’t authorized to use them that way. 

Access is not authorization 

Access is a technical fact: the credentials that an agent has. Authorization is an organizational decision: which actions, on whose behalf, for what purpose, and with whose sign-off. 

For employees, job descriptions and approval chains fill the gap between the two. A finance analyst may have access to the payments system, but that doesn’t mean they can wire money whenever they like. An agent has none of that context. It inherits the access of whoever deployed it and treats every permission as a mandate. So “limit what the agent can access” is necessary but incomplete. You can shrink the access surface and still have no answer to the question: what was this agent supposed to do? 

When permitted and intended come apart 

Aim Labs researchers disclosed EchoLeak, the first known zero-click attack on a major AI assistant, Microsoft 365 Copilot. A single email, never opened by the victim, carried hidden instructions. When the user later asked Copilot an unrelated question, it pulled in the attacker’s email, followed the instructions, and sent company data out disguised as an image request. 

There was no malware, no stolen passwords and no unusual login. Copilot simply used permissions the organization had granted, on behalf of someone it never authorized. Every technical control worked as configured. The failure was in governance. 

Why the agent can’t police itself 

A model reads its instructions, your request, and everything it retrieves as one stream of text. A malicious sentence in a calendar invite carries the same weight as a directive from the CEO. This is prompt injection, and it is a property of how these systems read, not a bug awaiting a patch. 

Like a toddler in a park, the agent can’t verify a stranger who says, “your mum told me it’s fine.” So, authorization can’t live in the prompt, because words can be overridden by other words. It must be enforced outside the model, in a layer the model can’t negotiate with. 

What an authorization model looks like 

  • Define authority before access. Write down what the agent may do, for whom, and what is out of bounds. If you can’t write the sentence, you’re not ready to deploy. 
  • Treat permissions as a ceiling, not a mandate. Scope credentials to the task, keep them short-lived, and assume every permission will eventually be misused. 
  • Rate actions by reversibility. Reversible actions run freely. Sensitive ones get an automated check that can only say no, since it is also a model and can be manipulated. Irreversible or external actions (deleting, paying, sending outside the organization) need a human to approve. 
  • Give every agent an owner who is accountable for its authority and can revoke it immediately. 
  • Log actions, not just outputs. A hijacked agent can complete a malicious task flawlessly while every test stays green. 

Why this matters in finance 

Fintech already has the vocabulary: segregation of duties, dual control, approval limits, audit trails. No bank lets one person create and release a payment. Same should be applied when the actor is AI. Auditors will ask who authorized the action, not what the agent’s token permitted. “The model decided it was good” won’t be an acceptable answer. 

Conclusion 

Locking down access answers only half of the question. The other half is what the agent is authorized to do. Who decided that, and what enforces it when the agent, or someone speaking through it, wants to do something else. Define what agents may do and enforce it outside the model. 

The article was published in The Bright Minded. You can read it here.

The Force That Fuels Digital Finance

Looking for a partner to relieve you from the minutia and complexity of financial services so you can focus on delivering great customer experiences?