Least Privilege at Machine Speed: Securing AI Agents in Financial Services

Financial institutions have spent years building controls around who can access data, approve transactions, change systems, and perform sensitive operations. AI agents are changing the question.

As agents move from answering questions to executing multi-step workflows, financial institutions need to decide not only who can access a system, but also what an AI agent can do, under which conditions, and how far it can go without human intervention.

That distinction matters because an agent can operate at machine speed. A human might review a handful of transactions or cases in an hour. An agent can query thousands of records, call multiple tools, and initiate actions across several systems in the same period.

Google Cloud’s 2026 financial services research highlights this shift toward agents across employees, workflows, customers, security, and scale. Google Cloud is also expanding its agent platform with capabilities such as Agent Identity, Agent Runtime, and Agent Gateway, providing organizations with new ways to manage agent identities, govern access, and run long-running agent workflows.

For financial institutions, that creates a familiar security principle with a new level of urgency: Least privilege has to operate at machine speed.

Why AI Agents Require a More Granular Approach to Least Privilege

The principle of least privilege is straightforward: give an identity only the permissions it needs to perform its job. That works well when the identity is a human employee with a defined role. A loan officer might need access to customer applications. A fraud analyst might need transaction data. A treasury employee might need access to specific payment workflows.

Agents are different. An agent’s capabilities can change depending on its purpose, tools, context, and workflow. A single agent might retrieve information from a database, call an API, use an external tool, generate a recommendation, and potentially trigger an action.

Giving that agent broad access because it “might need it later” creates a dangerous gap between what the agent needs and what it can actually do.

Consider a fraud-analysis agent. It may need to:

• Query transaction history
• Analyze account behavior
• Compare transactions against fraud signals
• Retrieve relevant customer information
• Produce a risk assessment

It doesn’t need to initiate a payment. If the same identity can both analyze a suspicious transaction and execute a transfer, the permission model has already gone too far. The same principle applies across financial services.

• A loan assistant may need to prepare an application but shouldn’t approve the loan.
• A wealth-management agent may analyze a portfolio but shouldn’t execute trades independently.
• A treasury agent may identify an optimal transaction and prepare it for execution, while a separate control process handles approval.

The goal is to make each agent capable of performing its job while keeping its authority tightly bounded.

A Practical Four-Level Model for Financial AI Agent Permissions

A useful way for financial institutions to structure agent authority is to separate capabilities into four levels:

Read → Analyze → Recommend → Transact

This isn’t an IAM role hierarchy. It’s a business risk framework that can help teams decide which permissions and controls an agent should require at each stage.

Each step increases the potential business impact of an agent’s actions. The security controls should become progressively stronger as the agent moves up the ladder.

Level 1: Read

At the first level, an agent can retrieve approved information but can’t modify anything.

Examples include:

• Reading account information
• Retrieving transaction history
• Querying product information
• Accessing approved financial reports
• Retrieving market or risk data
• Searching internal policies

A customer service agent, for example, might retrieve the information needed to answer a customer’s question. The important question is still: which information?

An agent supporting credit-card customers may need access to card status and recent transactions. That doesn’t automatically mean it needs access to investment accounts, internal risk models, or unrelated customer records.

This is where resource-level permissions, separate service accounts, and carefully scoped data access become important.

Level 2: Analyze

The next level allows the agent to process data and generate insights. This is where many financial AI use cases become particularly valuable.

A fraud agent could analyze transaction patterns and identify suspicious activity. A risk agent could evaluate a portfolio against predefined criteria. A credit agent could analyze application data and identify missing information or potential risk factors.

The agent is producing intelligence, but it’s still operating within an analytical boundary.

For example: Fraud agent: Read transactions → Analyze patterns → Assign risk score

The agent doesn’t need permission to freeze an account or move money simply because it can identify suspicious behavior. Keeping analytical authority separate from operational authority makes the architecture easier to reason about and easier to audit.

Level 3: Recommend

At this stage, the agent can turn analysis into an actionable recommendation. This is a significant step because the agent is now influencing a business decision.

• A lending agent could recommend whether an application should move to the next stage.
• A treasury agent could recommend a transaction based on liquidity, timing, and predefined rules.
• A wealth-management agent could recommend portfolio adjustments.
• A fraud agent could recommend reviewing an account or placing a transaction on hold for investigation.

The key control here is separation between recommendation and execution. An agent can have enough access to build a recommendation without having the authority to carry it out. That separation creates an important human-and-system control point.

Level 4: Transact

This is where the risk profile changes dramatically. An agent capable of executing an action can create a direct business consequence. Examples include:

• Initiating a payment
• Changing an account
• Approving a transaction
• Issuing a refund
• Executing a trade
• Changing a credit decision
• Modifying customer information

At this level, “least privilege” needs to become much more granular. An agent might be architecturally permitted to initiate payments below a defined threshold, within a specific account, during a defined period, and only after another system has validated the transaction. That is very different from giving the agent unrestricted transaction permissions.

The Permission Model Should Follow the Business Risk

The four levels provide a useful starting point, but financial institutions shouldn’t treat them as four static IAM roles. The actual permission model should consider several dimensions.

This is where conditional access becomes particularly powerful.

Google Cloud’s July 2026 IAM guidance shows how IAM Conditions can narrow permissions using attributes such as the resource being accessed, roles being granted, the MCP service or tool being called, and the time of a request. Google also recommends combining Allow and Deny policies to create a defense-in-depth approach.

For AI agents, this provides a way to move beyond broad statements such as: “This agent has access to BigQuery.” A more useful question is: “Which BigQuery data can this agent access, which operations can it perform, through which tools, and under what conditions?”

That level of precision becomes increasingly important as agents interact with more systems.

MCP Introduces Another Permission Boundary

The rise of Model Context Protocol, or MCP, adds another dimension to the problem. An agent may have access to a collection of tools that allow it to interact with enterprise systems. The security question then becomes whether the agent needs access to the entire toolset.

Google Cloud’s July 2026 IAM guidance provides an example of restricting an identity’s access to specific MCP servers and even individual MCP tools using IAM Conditions. For a financial institution, imagine an agent with access to a collection of banking tools. It might need:

Allowed

• Read customer profile
• Read transaction history
• Run a fraud-analysis query

Restricted

• Change customer details
• Initiate payment
• Approve transaction
• Delete records

The agent can still perform its intended workflow. Its toolset simply reflects its actual responsibilities. That distinction is critical because an agent doesn’t need malicious intent to create a security problem. A poorly scoped toolset can give an otherwise legitimate agent capabilities that its workflow never required.

Build Separation Between Recommendation and Execution

One of the most effective patterns for high-risk financial workflows is to separate the agent that makes a decision from the system or identity that executes it.

Consider a treasury workflow. An AI agent could:

1. Analyze cash positions
2. Review upcoming obligations
3. Identify liquidity requirements
4. Recommend a transfer
5. Generate the transaction details

A separate control layer could then validate:

• Transaction amount
• Source and destination accounts
• Business rules
• User authority
• Risk signals
• Approval requirements

Only after those checks pass would the transaction become executable.

This separation can reduce the potential impact of an agent compromise, configuration error, or unexpected model behavior by preventing the agent from directly exercising the highest-risk operation.

Instead of asking, “Why did the AI move the money?”, an institution can distinguish between:

• Agent: recommended the transaction.
• Policy engine: validated the transaction.
• Authorized control: approved the transaction.
• Execution service: performed the transaction.

Each component has a defined responsibility.

Design for Failure, Not Just Successful Workflows

Agent security also needs to account for what happens when things go wrong. An agent may encounter unexpected data, a failed API call, an ambiguous instruction, or a workflow that falls outside its normal operating conditions.

A secure architecture should define what the agent does when it reaches the boundary of its authority. For example:

• Within policy: Execute automatically.
• Requires additional context: Request clarification.
• Exceeds transaction threshold: Request approval.
• Touches restricted data: Block the request.
• Attempts an unauthorized tool call: Deny and log.
• Detects anomalous behavior: Stop the workflow and escalate.

This creates a controlled failure mode instead of allowing the agent to improvise around a permission boundary.

That’s particularly important for long-running agents. Google Cloud’s Agent Executor, currently available in preview, is designed to support durable execution and human-in-the-loop interruptions for long-running agent workflows.

A Practical Agent Permission Matrix

The following matrix is a business-risk framework for defining agent authority. It doesn’t represent predefined Google Cloud IAM roles. Financial institutions can turn these principles into an operational framework by defining the authority and permissions for each agent before it reaches production.

For example:

The exact permissions will vary by institution, but the exercise forces an important conversation. What does this agent actually need to do its job? And equally important: What could it do if its credentials were misused? That second question often exposes permissions that have accumulated simply because they were convenient during development.

Least Privilege Needs to Become Continuous

Agent permissions shouldn’t be treated as a one-time configuration exercise.

Agents evolve. Their tools change. Models change. Workflows expand. New data sources are connected. An agent that was initially designed for analysis might eventually gain the ability to trigger actions. That means financial institutions need to continuously review:

• Which agents exist
• Which identities they use
• Which data they can access
• Which tools they can call
• Which actions they can perform
• Which permissions are actually being used
• Which actions require human approval
• Which policies can be tightened

This becomes particularly important as organizations face agent sprawl and dormant permissions. Google Cloud’s agent governance capabilities include agent discovery and observability, helping organizations understand which agents exist, what they can access, and how they behave over time.

This is where observability and governance become part of the security model. The objective isn’t simply to create a secure agent on day one. It’s to prevent an agent’s effective authority from quietly expanding over time.

From AI Access to AI Authority

Financial institutions have already learned how important identity and access management are for people, applications, and workloads. AI agents extend that same problem into a new operating model.

An agent can have an identity, access data, call tools, make decisions, and trigger workflows. Once it reaches that level, treating it as “just an AI application” leaves an important part of the security architecture undefined.

The more useful model is to think in terms of authority.

• Read gives an agent context.
• Analyze gives it intelligence.
• Recommend gives it influence.
• Transact gives it operational power.

Each step should come with progressively stronger controls.

Google Cloud’s agent platform provides capabilities to build and govern agents at enterprise scale, while IAM Conditions and Deny policies provide mechanisms to narrow and enforce access. But the technology is only part of the equation.

Financial institutions still need to decide what each agent should be allowed to do, where its authority should stop, and when another control should take over. The future of financial AI won’t depend only on building smarter agents. It will depend on building agents whose authority is as carefully engineered as their intelligence.

Building Secure Agentic Foundations

For financial institutions exploring agentic AI, the starting point shouldn’t be “What can we automate?” It should be: “What level of authority can we safely give an agent for this workflow?”

Kartaca helps organizations design cloud and data architectures that support AI workloads with the security, governance, scalability, and operational controls required for production. From cloud foundations and data platforms to AI and workload modernization, we can help you translate agentic AI opportunities into architectures that are built for controlled execution.

Contact us today to start building your secure foundation for agentic AI.