Writing

Giving an Agent the Keys: Access Control Lessons from Automating Live Financial Operations

Lanre Ibraheem, Founder and Principal  ·  March 2026

Every board now wants agents. The demos are persuasive, the vendors even more so, and the pressure to put an agent against real operations is arriving faster than the discipline for doing it safely. I have spent the past year building and governing agentic systems inside a platform that moves serious money across many countries, and the most important thing I learned is that access, not model quality, is where these systems fail first.

A model that hallucinates gives you a wrong sentence. Hand the wrong credentials to an agent and you can get a wrong transaction, which is a different class of problem altogether, and the one that should keep an engineering leader awake.

The inheritance problem

Here is how it goes wrong in practice. An agent is deployed as a tool inside an operations platform. To act, it needs credentials, and the path of least resistance is to let it inherit the token of whoever invoked it. In most companies the people invoking new AI tooling are senior operators and administrators, so the agent quietly inherits administrator scope. Nobody decided this. It fell out of the architecture.

Now the blast radius of a misunderstood instruction is everything the administrator can touch. The agent was asked to resolve one issue in one workflow, and it is technically capable of touching every record in the system. When we audited our own early deployments this was the single largest gap, and when I look at other companies claiming agentic capability, I find it almost every time.

Scope to the intent, not the identity

The fix is a change in the question. Traditional access control asks who is acting. For agents, the better question is what is being attempted. An agent invoked to resolve a payment discrepancy should receive a credential scoped to that intent: the specific records, the specific operations, nothing else. The invoking user’s identity still matters for authorisation and audit, but it should set the ceiling, never the default.

Practically, this means minting a purpose bound token at invocation time. Ours live for one to three minutes. If a workflow legitimately takes longer, the token is reissued at defined checkpoints rather than extended. Long lived agent credentials are how a contained mistake becomes an incident with a timeline.

Restrict the map, not just the key

Scoped tokens are necessary and insufficient. The other half is restricting which endpoints an agent can see at all for a given workflow. An agent resolving a discrepancy has no reason to know that a force completion endpoint exists. If it can see it, some percentage of the time it will reason its way into calling it, and the reasoning will even look sensible in the log.

Discovering which endpoints each workflow genuinely needs is unglamorous work. The most reliable method we found was reading audit trails: take months of real human executions of the workflow, extract the set of operations actually used, and make that set the allow list. The gap between what operators theoretically could use and what they actually used was enormous, and that gap is exactly the attack surface you remove.

Ambiguity is an access problem wearing a language costume

One lesson I did not expect. In any platform that grew across domains, the same word means different things in different places. A term like approval or completion can refer to materially different operations depending on which part of the system you are in. Humans disambiguate from context without noticing. Agents do not, and an agent that resolves a word to the wrong operation is indistinguishable, at the access layer, from an agent doing its job.

Before wide agent deployment, the vocabulary of the system needs the same treatment as its permissions: a single nomenclature, mapped explicitly to operations, so that intent expressed in language resolves deterministically. This is tedious work, and it accounts for most of the distance between an agent that looks safe in a demo and one that survives production.

Decide what should not be an agent

The last discipline is refusing the premise where the premise is wrong. Plenty of workflows that get proposed for agents are better served by deterministic code with an agent at the edges, handling interpretation and summarisation while the state changes stay conventional. My rule of thumb is that a workflow with a correct answer and a financial cost of deviation gets a deterministic core and an agent interface. Where the work instead requires judgment across messy inputs, with a human reviewing the output, the agent can own more of it.

Evaluation ties it together. Not evaluation as a dashboard, but as a gate: defined suites the agent must pass before any expansion of its access, rerun on every change to model, prompt, or tooling. Access and capability should grow together, and only with evidence.

None of this is exotic. It is the same least privilege thinking security teams have preached for decades, applied to a new kind of actor that moves faster than any human and carries none of a human’s fear of consequences. The companies I see getting agents right are distinguished less by their models than by how seriously they treated access as part of the product.