Agentic AI Architecture Series | By Hany Tadros
Day One, Two Very Different Experiences
When a new analyst joins a bank, the onboarding machinery is impressive. There is a background check, a badge with a photo, and a manager who signs off on every entitlement. Access is granted by role, reviewed every quarter, and revoked the day the person leaves. Every trade, approval and report they touch carries their name.
Now picture the onboarding of a new Artificial Intelligence (AI) agent at the same bank. Too often it looks like this: a developer creates a service account, pastes a long-lived Application Programming Interface (API) key into a configuration file, and grants whatever permissions made the demo work. Nobody is named as the agent's manager. Nobody reviews its access next quarter. Nobody has a plan for the day it should be retired.
The agent can read customer data, call internal systems and, in some cases, initiate transactions. It simply has no badge.
What Accenture Is Telling Banks
Accenture's Top Banking Trends 2026 report describes an era of "Unconstrained Banking" where small teams orchestrate AI agents to deliver scale that was not previously possible.
Buried in that optimism is a hard requirement: as agents spread across banking operations, Accenture argues they must be plugged into the enterprise technology stack with their own defined identity and access controls. The firm recommends that executives establish an agent identity framework covering authentication, authorization and permissions, and that banks build Agent Operations (AgentOps) functions to manage and govern agent deployment.
The adoption numbers explain the urgency. According to the report, 57% of banking executives expect AI agents to be fully embedded within three years in risk,compliance and audit, as well as fraud detection and transaction monitoring.Separately, the Capgemini Research Institute's World Cloud Report for Financial Services 2026 found that nearly half of banks and insurers are creating roles to supervise AI agents.
Read that list of functions again. Risk, compliance, audit and transaction monitoring are exactly the places where a bank must prove to examiners who did what, when and on whose authority. An agent operating there without a verifiable identity is not an innovation. It is a control finding waiting to be written.
The Gap Is Real, and It Is Measurable
The industry data on non-human identity governance in 2026 is sobering:
A January 2026 Cloud Security Alliance (CSA) and Oasis Security survey of 383 IT and security professionals found that 92% are not confident their legacy Identity and Access Management (IAM) tools can manage AI and non-human identity risk, and 78% have no documented, formally adopted policy for creating or removing AI agent identities.
A separate CSA and Aembit survey found that 31% of organizations run agents under delegated human user identities, and only 36% assign a dedicated identity to each AI agent.
Research from Rubrik Zero Labs, cited by CSA, estimates that non-human identities now outnumber human users by 82 to 1 in enterprise environments.
A 1Password survey fielded in mid-2026 found that agents touched roughly twice as much data as anyone had approved.
A 2026 Teleport study of more than 200 United States infrastructure security leaders reported a 17% security incident rate among organizations enforcing least privilege on their AI systems, versus 76% among those that did not.
In plain terms, most organizations are giving their fastest-growing workforce their weakest identity controls.
Why an Agent Is Not Just Another Service Account
Banks have managed Non-Human Identities (NHIs) for decades: batch jobs, service accounts, system-to-system API keys. A fair question is why agents need anything new.
There are four reasons:
Agents decide.A batch job does the same thing every night. An agent chooses which tool to call based on reasoning that can be influenced by the content it reads. A poisoned email or document can redirect it through prompt injection.
Agents act on behalf of people.When an agent works for a relationship manager, every action has two principles: the human who delegated and the agent who executed. Most IAM systems record only one of them.
Agents multiply.An orchestrator can spawn sub-agents and hand tasks to other agents, so a single request can cross several identities in seconds.
Agents accumulate.Permissions added for a pilot are rarely removed. An agent that started by reading one data set can end up with write access to five.
The Open Worldwide Application Security Project(OWASP) Top 10 for Agentic Applications, published in December 2025, captures this as Identity and Privilege Abuse (ASI03): agents holding more identity or privilege than the task in front of them needs. Its core mitigation is simple and worth adopting as policy: each agent gets its own machine identity, never a shared service account, and that identity can be revoked on its own.
Pillar 1: Give Every Agent a Badge
Identity comes before access. Treat every agent as a first-class principal in your identity fabric.
One agent, one identity.No shared service accounts and no borrowed human credentials. If you cannot tell two agents apart in your logs, you cannot govern either of them.
An agent inventory with an accountable human owner.Record the business purpose, risk tier, model and version, approved tools, data classifications and autonomy level for every agent.
Joiner, mover, leaver for agents.Provision agents through the same workflow as people. A change of model, tool set or data scope triggers re-approval. Every agent has a planned review or decommission date, and orphan detection flags agents whose owner has left the bank.
Independent revocation.You should be able to switch off one misbehaving agent in minutes without taking down the whole platform.
Pillar 2: Least Privilege for Workers Who Never Sleep
Least privilege for a human is scoped to a role. For an agent, it should be scoped to a task.
Deny by default.Agents get an explicit allow-list of tools and data, nothing more.
Tier the actions.Separate read, write and transact permissions. Most first-wave banking agents should be read-and-recommend, with a human making the final call.
Apply the intersection rule.When an agent acts on behalf of a user, its effective permissions are the intersection of the agent's rights and the user's rights, never the union. An agent must never let a junior analyst do something the analyst could not do directly. That is the classic confused deputy problem, and agents make it easy to create.
Enforce Segregation of Duties (SoD).The agent that prepares a payment cannot approve it. The agent that builds a model cannot validate it. Maker and checker need separate identities.
Use Just-in-Time (JIT) elevation.High-impact actions, such as moving money or changing customer records, require a time-boxed elevation with human approval that expires automatically.
Recertify like you do for people.Include agents in quarterly user access reviews and use actual usage data to strip entitlements the agent never exercises.
Pillar 3: Credential Scoping, Keys That Expire Before They Can Be Stolen
Most agent breaches will not start with a clever model exploit. They will start with a credential that was too broad, lived too long or sat in the wrong place.
No static secrets in code, prompts or configuration files.Credentials live in a vault and are issued at runtime.
Short-lived tokens.Measure credential lifetime in minutes, not months.
Audience-restricted tokens.A token issued for the payments API should be useless if replayed against the customer data API.
Carry the delegation in the token.Open Authorization (OAuth) 2.0 Token Exchange, defined in Request for Comments (RFC) 8693, allows a token to identify both the user and the agent acting for that user, so downstream systems can enforce the intersection rule.
Keep credentials out of the model's context window.The model asks for an action; a broker or gateway attaches the credential outside the reasoning loop. A secret the model never sees cannot be leaked through a prompt.
Enforce at the tool gateway.Model Context Protocol (MCP) servers and API gateways become policy enforcement points, checking authorization on every call rather than once per session.
Pillar 4: Audit Trails That Can Answer an Examiner
An agent audit trail should answer five questions without a forensic project: Who acted? On whose authority? With what permission? What did it do, and why? What changed?
Log the full chain.Capture the human request, the agent identity, the delegating user, the model and version, the prompt and policy versions, the plan, every tool call with its parameters, the authorization decision and the result.
Correlate across hops.A single correlation identifier follows a request through every agent and sub-agent it touches.
Make agents visible as agents.Tag agent activity distinctly from human activity. Many organizations today cannot tell the difference in their own logs.
Make logs tamper-evident.Store them immutably and retain them in line with records management requirements.
Watch behavior, not just events.Baseline normal patterns for each agent and alert on anomalies such as a new tool, a volume spike or off-hours data pulls.
Serve the second and third lines.Design the trail so model risk management and internal audit can use it directly, not only the security operations team.
Where the Standards Are Heading
Regulators and standards bodies are moving. On February 5, 2026, the National Institute of Standards and Technology (NIST) National Cybersecurity Center of Excellence (NCCoE) released a concept paper on applying identity and authorization standards to software and AI agents. It drew more than 600 responses, and the NCCoE is now standing up a project whose final deliverable is a Special Publication (SP) 1800 series practice guide with example implementations. The concept paper points to OAuth 2.0, its extensions and policy-based access control as the building blocks for agent rights and entitlements.
The message for banks is clear
The direction of travel is to extend proven identity disciplines to agents, not to invent a parallel universe. Start now and you will not be early. You will simply be ready when the guidance lands.
A Practical Checklist for Banking Leaders
Closing: A Badge, a Manager, a Job Description and an Exit Date
The banks that scale agents safely will not invent a new discipline. They will extend the one they already have. Every human in a bank has a badge, a manager, a job description and an exit date. Give your agents the same four things, enforce them in code rather than in policy documents alone, and log every move.
The question for your next governance committee is not whether agents will join the workforce. It is whether you will know who they are when they do.
Question for you: Does your organization treat AI agents as first-class identities today, or are they still borrowing someone else's badge? I would love to hear how you are approaching it in the comments.
Explore more: Start Here · Topics · Archive · About