Technical Guide

The ultimate guide to AI Agent identities across AWS, Azure & GCP

Behind every AI agent is an identity that needs to be authenticated, authorized, and monitored. But across AWS, Azure, and GCP, those identities behave differently. If you're a security practitioner, this is your practical guide to architecting a consistent, secure approach across multi-cloud environments.

Get started

Technical Guide

The ultimate guide to AI Agent identities across AWS, Azure & GCP

Behind every AI agent is an identity that needs to be authenticated, authorized, and monitored. But across AWS, Azure, and GCP, those identities behave differently. If you're a security practitioner, this is your practical guide to architecting a consistent, secure approach across multi-cloud environments.

Get started
Table of Contents

Demo

See the Silverfort platform in action

See why top enterprises trust us to secure what others can’t.

Get a demo

Section 1

Why this guide exists

Your AI agents are already acting as identities. The question is: do you know which ones?

When an agent sends an email, it’s authenticating as someone. When it queries a database, it has someone’s permissions. When it accesses a file share, someone appears in the audit logs. But who?

Here’s what vendor documentation won’t tell you:

  • Azure agents can act under multiple identities in a single conversation—user, maker, and the agent itself
  • GCP’s default configuration shares a single identity across all your agents within a single project
  • AWS gives you full control, which means misconfiguration is entirely on you

This guide covers what the platform docs don’t: not how to configure agents, but what identities they actually use when they act, and what that means for your security posture.

The three platforms at a glance:

Platform

Identity Philosophy

AWS

Your account, your identity. Full control, full responsibility.

Azure

Flexible identity for enterprise complexity.

GCP

Managed infrastructure, configurable identity.

Who this guide is for:

Security leaders responsible for IAM, cloud security, or AI governance in production environments.

What you'll learn:

  • Why agent identity is different from traditional non-human identities
  • How each major cloud platform conceptualizes agent identity
  • Which identity model each platform uses (with specific examples)
  • The key identity risks for each platform
  • Actionable checklists for identity management

Before we dive in, ask yourself:

  • Do you know which identities your agents use per tool?
  • Can a low-privilege user trigger high-privilege actions through an agent?
  • Can you revoke agent access without redeploying code?
  • Do you have a single audit trail for each agent's actions?
  • Can you trace it back to an employee?

If you answered “no” to any of these, you’re not alone—and this guide will help.

This is not a generic cloud security guide. This is specifically about agent identity—in other words, who the agent is when it acts.

Key insight

You can't predict what an AI agent will do next.

This isn’t a bug—it’s the whole point. Agents are valuable because they’re adaptive. But that adaptivity creates Identity Security challenges that traditional NHI controls weren’t designed for.

Section 2

Why agent identities are different

Before diving into platform specifics, let’s look at what makes AI agent identities unique. This context is essential for evaluating the platform-specific guidance that follows.

Quick comparison: Human vs traditional NHI vs AI Agent

Dimension

Human

Traditional NHI

Identity Philosophy

Behavior

Variable, judgment-based

Deterministic, scripted

Non-deterministic, adaptive

Decision-making

Contextual, accountable

Pre-programmed or none

Model-based, context-aware

Access patterns

Variable, auditable

Predictable, consistent

Variable, task-dependent

Permissions

Role-based, reviewable

Static, long-lived

Variable, task-dependent

Susceptibility to adversarial input

Social engineering

Requires credential theft or code/config change

Prompt/tool input subversion

Three unique identity risks for agents

1. Decision hijacking via manipulation 

Service accounts execute deterministic workflows. To change what they do, an attacker typically needs control over the workflow’s code or its runtime configuration/inputs.

In contrast, AI agents respond to prompts. To change what they do, you need to craft the right input.

Implication: Prompt injection subverts an agent’s decision-making while operating under a valid identity, producing effects similar to identity takeover without compromising credentials. The identity doesn’t change; it’s the agent’s tool-selection, actions, and decisions made under that identity that are hijacked. Traditional access controls can’t prevent this.

Example: An attacker embeds instructions in a document the agent processes, causing it to call its authorized SQL connector with SELECT * FROM customers WHERE credit_limit > 100000 and pass the results to its email tool — both tools are permitted, but the query and exfiltration path were never intended.

2. Credential sprawl across interaction surfaces  

Traditional NHI credentials (service accounts, API keys) typically leak via code/config surfaces: committed secrets, config files, environment variables.

Agents increase leakage paths because secrets can pass through natural language prompts/responses, tool I/O, chat transcripts, and debug logs, especially during development and troubleshooting. This is avoidable with good design, but common in early deployments.

Example: Agent accidentally includes API key in a response, or user prompt includes sensitive credentials that the agent exposes.

Implication: Credential hygiene must extend to agent I/O, not just code and config.

Design principle: Keep secrets out of the natural-language loop. Pass credentials through secure connectors/secret managers and structured tool parameters, not prompt text.

3. Dynamic permission requirements 

Service accounts run scheduled, predictable jobs, so it’s easy to establish a baseline of what’s “normal”. Static permissions work for service accounts because their behavior is static. 

AI agents respond to user requests, so each interaction is different. “Normal” changes constantly. Static permissions either over-provision (leading to risk) or under-provision (leading to broken functionality). Users are part of the access boundary. A low-privilege user can trigger a high-privilege action if the agent’s tool identity is over-scoped or delegated from a privileged maker/service account. 

Implication: Agents need permissions scoped to the specific task, not permanent broad access.  

Example: Grant read access to a database only for the duration of a query, not permanently. Traditional anomaly detection (i.e., deviation from baseline) doesn’t work well because you can’t predict what an AI agent will do next. 

Why traditional NHI controls are insufficient

Traditional approach

Why it fails for agents

Grant permanent, broad permissions

Agents need dynamic permissions scoped to the specific task

Static permission assignments

Even with short-lived tokens, permission scope is often static and overly broad

Monitor for schedule deviations

Agents don't have predictable schedules

Annual access reviews

In fast-moving environments, agents may be created and modified frequently

Assume consistent behavior

Agents are inherently variable

A note on terminology:

Each cloud provider exposes multiple "agent-like" constructs under different branding—Bedrock Agents, Copilot Studio agents, AI Foundry projects, Vertex AI agents, and more. For this guide, we define "agent" as any AI-driven system that can autonomously invoke tools or access resources under an identity. The specific product name matters less than the identity model it uses.

If you're multi-cloud:

You're managing multiple identity models simultaneously. Each platform section below is self-contained, but it’s important to recognize that your governance challenge compounds across clouds.

Section 3

How agent identities work on each platform

The core question: Who IS this agent? 

Each cloud answers this differently based on their identity philosophy. Before diving into specifics, here’s a unifying framework for thinking about the differences. 

The identity spectrum: Ownership → delegation → opacity

All agent identity models fall somewhere on this spectrum: 

Position

What it means

Example

Ownership

You own and control all identity components

AWS

Delegation

Identity shifts depending on context

Azure

Opacity

Provider-managed runtime with limited customer inspection/telemetry into the execution context

GCP

Platforms can span more than one position depending on the product (e.g., Copilot Studio vs Foundry). 

These models optimize different things:  

  • Ownership maximizes customer control and clear blast-radius boundaries but requires disciplined IAM engineering 
  • Delegation can improve human accountability (i.e., actions tied to the initiator) but introduces mixed identity contexts and increases the risk of privilege inheritance through connectors/makers 
  • Opacity reduces operational overhead but limits inspection and forensics 

Keep this spectrum in mind as you read each platform’s approach. 

TL;DR

AWS: Your account, your identity.

Full control means full responsibility—map IAM roles, enforce least privilege, own your mistakes.

Identity Management Checklist

  • Map agent → execution role → (tool-related roles if applicable)
  • Review permissions on each role (Least Privilege)
  • Track agent lineage: who created it, what tools it uses, and (for chat-based agents) which users can invoke it
  • Use permission boundaries (IAM guardrails that set the maximum permissions a role can have, regardless of what policies are attached)
  • Monitor role assumptions for anomalies (unexpected times, unusual frequency, unfamiliar source IPs, or access to resources outside the agent's expected scope)

AWS: Your account, your identity (Bedrock & AgentCore)

The AWS philosophy 

AWS treats AI agents the same way it treats any workload: identity enforcement is rooted in your account. That means your IAM roles, your S3 buckets, your CloudWatch logs. While Bedrock itself is a managed service (AWS operates the runtime), your identity controls—the roles, policies, and audit trails—live in your account. 

Identity in AWS is always IAM. An agent’s identity is an IAM role, just like a Lambda function or an EC2 instance. If you know how to secure IAM, you have the foundation to secure agent identity (though agents introduce unique risks, as covered in Section 2). 

How this applies to Bedrock agents 

AWS Bedrock is Amazon’s managed service for building AI agents. When you create a Bedrock agent, AWS provisions everything within your account—but you need to understand how identity is structured. 

Every Bedrock agent has an Agent Execution Role, the primary identity the agent uses to act. 

If the agent has action groups (the tools and capabilities you configure for your agent), each action group has identity implications: 

Action group type

Identity Impact

Lambda function

Lambda executes under its own execution role (separate from the agent role). The Lambda can call external APIs, access AWS services, or perform custom logic, all under its IAM role.

Return control

No additional role; action returns control to the calling application, which handles execution under its own identity.

The result

One agent can involve multiple IAM roles, depending on the action group configuration—the agent execution role, plus any Lambda execution roles or other service roles invoked by the action groups. You create and manage these roles. Bedrock doesn't create them for you. 

What this means for you:

  • You can see what the agent is allowed to access within AWS (via IAM policies), but logs won't tell you why the agent decided to access something
  • You control the identity and you are responsible for securing it
  • Standard AWS security patterns apply directly

Key question to answer:

Which IAM roles belong to which agents?

Key identity risk:

Overprivileged roles that grant more access than the agent needs. 

Because you create the IAM role, getting it wrong is on you. Start with minimal permissions and expand only with justification. 

Impact if compromised:

Overprivileged roles that grant more access than the agent needs. Because you create the IAM role, getting it wrong is on you. Start with minimal permissions and expand only with justification.

Whether through credential theft, over-permissioning, or prompt manipulation that causes unintended actions: 

Attacker gains access to everything the agent execution role can touch: foundation models, S3 buckets, knowledge bases, plus any additional IAM roles if action groups invoke other AWS services (Lambda functions, API Gateway endpoints, etc.). 

The blast radius is bounded by IAM permissions you configured. 

Also in AWS: AgentCore (Code-First)

For developers building agents in code (not Bedrock’s no-code UI), AWS offers AgentCore. The identity model follows the same AWS philosophy, where agents use IAM roles, but with key differences: 

Code-first identity definition: Unlike Bedrock’s console-based configuration, AgentCore identity is defined through infrastructure-as-code and deployment configurations. IAM roles are typically specified in application manifests or IaC templates, giving developers full control but requiring them to get it right. 

Higher misconfiguration risk: Because identity is code-defined, AgentCore carries a higher risk of: 

  • Overprivileged roles hardcoded in application configs 
  • Embedded credentials in source code 
  • Inconsistent permission scoping across environments (dev/staging/prod) 
  • Credentials accidentally committed to version control (exposed in Git history even after deletion) 

Developer responsibility: Correct permission scoping falls primarily on the development team, with less console-based guidance than Bedrock’s managed approach. No wizard guides Least-Privilege configuration. 

It has the same IAM foundation as Bedrock, but the operational risks shift from admin misconfiguration to developer misconfiguration. 

Identity drift across agent versions (AWS Bedrock)

Bedrock supports versions and aliases for agents. An alias can route traffic to different agent versions, which is useful for gradual rollouts or A/B testing. However, this creates an identity governance risk. 

Different versions may have different: 

  • Execution roles 
  • Guardrail configurations 
  • Permission scopes 

The risk: Security teams may believe an agent is protected because the current version has appropriate guardrails, while traffic is actually being routed to an older, less-restricted version via an alias. This is a lifecycle and governance risk, not a vulnerability in Bedrock itself, but it requires explicit version/alias management in your agent security program. 

TL;DR

Azure: Multiple identities, one agent.

The flexible authentication model enables enterprise integrations but fragments accountability. Know which authentication mode each connector uses.

Identity Management Checklist

  • Map which identity mode each connector uses
  • Audit maker permissions (consider dedicated service accounts)
  • Know that one agent can result in three audit trail locations
  • Create dedicated accounts for connector ownership (not personal accounts)
  • Plan for connector owner lifecycle (what happens when they leave?)

Azure/Microsoft: Flexible identity for enterprise complexity

The Microsoft philosophy 

Microsoft recognizes that enterprise environments are complex. Different connectors need different authentications: sometimes the user should authenticate, sometimes a service account, sometimes the person who built the agent. Rather than forcing one model, Azure supports multiple identity modes simultaneously. 

This flexibility enables powerful integrations but creates complexity: the same agent can act as different identities depending on what it’s doing. 

How this applies to Copilot Studio 

Microsoft documents two primary authentication modes for Copilot Studio actions:

Authentication mode

When used

Who's "acting"

Audit shows

User authentication

When access must be restricted to specific users

The user talking to the agent

User

Agent author authentication

For implicit or low-risk access

For implicit or low-risk access

Maker

In practice, a third identity artifact also appears: the agent’s own service principal (an Entra ID application identity) used for certain API calls. This means a single agent can produce audit entries under three different identities depending on what it’s doing. 

Example flow: User asks agent to “summarize our sales pipeline and notify me”: 

  1. Agent queries CRM using agent author’s connection 
  2. Posts summary to Teams  using agent service principal 
  3. Sends email using user’s delegated permissions 

Three actions, three identities, one conversation. 

What this means for you:

  • Audit trails fragment across identity contexts, so correlating who decided, who executed, and who was affected is non-trivial
  • Low-privilege users can access high-privilege resources via maker credentials

Key question to answer:

Which authentication mode does each connector use?

Key identity risk:

Privilege escalation via agent author credentials.

If the maker (whoever set up the connector) has elevated permissions, every user of that agent inherits those permissions for actions using that connector. 

Microsoft recommends user authentication when access must be restricted to specific users; agent author authentication is positioned for implicit or low-risk access scenarios. Using maker credentials can lead to oversharing of data or capabilities. 

Impact if compromised:

Whether through credential theft, maker account compromise, or prompt manipulation: 

Blast radius depends on which identity mode was used and the tools/scope of access configured to the agent. In a worst case scenario, the maker has admin rights, so every user inherits those rights for that connector. Investigation requires correlating three separate audit locations. 

Identity Management Checklist

  • Map which identity mode each connector uses
  • Audit maker permissions (consider dedicated service accounts)
  • Know that one agent can result in three audit trail locations
  • Create dedicated accounts for connector ownership (not personal accounts)
  • Plan for connector owner lifecycle (what happens when they leave?)

Also in Azure: Microsoft Foundry (formerly AI Foundry)

Identity behavior still evolving, so treat this as distinct from Copilot Studio. 

Microsoft Foundry is Azure’s code-first platform for building AI agents, distinct from Copilot Studio’s no-code approach. It exists in two forms: 

  • Foundry classic: The original release 
  • Foundry (new): The current iteration with updated identity semantics 

 

Identity behavior differs between classic and new. In the new Foundry, agents can use an explicit Agent ID for identification. However, if an agent is not published, identity may be project-scoped rather than agent-specific. 

Identity semantics are still evolving. Not all execution paths have been fully researched—behavior may vary based on deployment state, configuration, and Foundry version. 

TL;DR

GCP: Managed simplicity, limited visibility

Avoid the default service account trap. Accept that you can’t see inside Google’s infrastructure.

Identity Management Checklist

  • Verify that agents don't use the default Reasoning Engine service agent
  • Check for pattern: service-{PROJECT_NUMBER}@gcp-sa-aiplatform-re... (default)
  • Prefer custom service accounts for production workloads
  • Accept limited infrastructure visibility and design for it
  • Document the service account model for compliance

GCP: Managed infrastructure, configurable identity

The GCP philosophy 

GCP optimizes for simplicity: Google manages the infrastructure, you configure the identity.  

The execution environment is managed and opaque: you can’t inspect the underlying runtime, even though IAM is configured through your project. This reduces operational burden but limits visibility. 

Identity in GCP is service accounts. You choose whether to use a custom service account or rely on Google’s default service agent, and that choice determines your isolation level. 

How this applies to Vertex AI Agent Engine (Reasoning Engine) 

When you deploy an agent, identity works in two layers: 

Layer 1: Google-managed service agent 
Google automatically creates a Reasoning Engine service agent for your project. This is required for deployed agents to function. It’s project-scoped and Google-managed—you can’t avoid it. 

Layer 2: Your service account choice 
For your agent’s actual resource access, you choose: 

Option

What it is

Isolation level

Custom service account

You create a specific SA for the agent

Best (recommended for production)

Default service agent

Use the Google-managed project S

Poor (shared across all agents in project)

Critical

If you don't explicitly configure a custom service account, your agent uses the default service agent—which is shared across all agents in your project. One compromised agent = all agents exposed.

What this means for you:

  • Identity choice happens at deployment, so configure custom SAs upfront
  • Default service agent = all agents in a project share one identity = bad isolation
  • Custom service accounts = each agent has its own identity = good isolation
  • Limited visibility into Google-managed infrastructure (you see logs, not runtime)

Key question to answer:

Is this agent using a custom service account or the default service agent?

Key identity risk:

Default SA has broad BigQuery/Storage access by default. If multiple agents share it, compromising one compromises all.

Default SA has broad BigQuery/Storage access by default. If multiple agents share it, compromising one compromises all. 

Impact if compromised:

Whether through credential theft, maker account compromise, or prompt manipulation: 

Blast radius depends on which identity mode was used and the tools/scope of access configured to the agent. In a worst case scenario, the maker has admin rights, so every user inherits those rights for that connector. Investigation requires correlating three separate audit locations. 

Identity Management Checklist

  • Verify that agents don't use the default Reasoning Engine service agent
  • Check for pattern: service-{PROJECT_NUMBER}@gcp-sa-aiplatform-re... (default)
  • Prefer custom service accounts for production workloads
  • Accept limited infrastructure visibility and design for it
  • Document the service account model for compliance

How to identify the default Service Agent

Look for this pattern in your service account configuration: 

service-{PROJECT_NUMBER}@gcp-sa-aiplatform-re.iam.gserviceaccount.com 

The -re suffix indicates the Reasoning Engine service agent. This is Google-managed and project-scoped, meaning it’s shared across all agents in your project unless you configure custom service accounts. 

Protocols & orchestration multiply identity risk

Beyond the platform-specific identity models covered above, several cross-cutting mechanisms add complexity: 

  • MCP (Model Context Protocol) — Standardizes how agents connect to tools 
  • Agent-to-agent (A2A) communication — Agents invoking other agents 
  • Workflow orchestration — Chains of agent actions coordinated by external systems 

Critical point: These mechanisms abstract tool access but do not define identity, authorization, or delegation semantics. The protocol handles how to connect, not who is authorized. 

When agents call other agents, or when workflows chain multiple agent actions, identity attribution becomes transitive. A user triggers Agent A, which calls Agent B, which accesses a database. The audit trail fragments. Whose identity is on the database access: Agent A’s, Agent B’s, or the original user’s? 

This compounds the governance challenges outlined for each platform. Protocols are plumbing—they don’t solve the identity problem. 

Where this is going

Today's agents use tools. Tomorrow's agents will create agents. 

When an agent can spawn sub-agents—each with their own identity—identity sprawl becomes recursive. A single user request could trigger an agent that creates three sub-agents, each accessing different systems under different identities, some of which may create their own sub-agents. 

This isn’t science fiction. Multi-agent orchestration is already in production at leading organizations. The identity management challenges we’ve outlined in this guide will compound. 

For now, focus on the single-agent identity models above. Multi-agent governance is the next frontier—but you can’t get there without solving single-agent identity first. 

TL;DR

A snapshot of the playbook

Here's a condensed view of the best practices we'll dive into in more detail on the left.

Discovery & inventory

  • Catalog agents by platform
  • Map service accounts/roles per agent
  • Document ownership
  • Classify by risk level

Credential & permission management

  • Use short-lived tokens
  • Enable automatic rotation
  • Prioritize Least Privilege
  • Store securely

Monitoring & response

  • Use centralized logging
  • Enable agent-specific alerting

Section 4

Identity best practices playbook

The following checklists condense the platform-specific guidance above into actionable items. Use them as a starting point for your agent identity program.

Discovery & inventory 

Before you can secure agents, you need to know what you have. 

Catalog agents by platform 

 Include dev/test/staging, not just production

  • List all AWS Bedrock agents (check Bedrock console, CloudFormation)
  • List all Azure Copilot Studio agents (Power Platform admin center)
  • List all GCP Vertex AI agents (Vertex AI console)
Map service accounts/roles per agent 

Agent

Platform

Primary Identity

Secondary identities

Example

AWS

Agent execution role ARN

Tool-related role ARNs (Lambda, API Gateway, etc.)

Example

Azure

Service principal

Maker credentials, User delegation

Example

GCP

Service account email

N/A

  • For AWS: Document execution role + all tool-related roles (Lambda, API Gateway, etc.)
  • For Azure: Document service principal + all connector identity modes
  • For GCP: Document service account model (custom/auto/default)
Document ownership
  • Document the creator, identity owner, and who can modify permissions for each agent
  • Verify ownership is functional accounts, not personal accounts
Classify by risk level

Risk level

Criteria

Review Frequency

High

Accesses PII, financial data, admin systems

Weekly

Medium

Accesses business data, internal systems

Monthly

Low

Read-only, public data, sandbox

Quarterly

  • Assign risk level to each agent and schedule reviews accordingly
Credential & permission management
Short-lived tokens
  • Use tokens with <1 hour lifetime for sensitive operations
  • Prefer OAuth/OIDC over static API keys
  • Avoid long-lived service account keys
Automatic rotation
  • Enable automatic credential rotation where supported
  • For AWS: Use IAM roles (automatic rotation built-in)
  • For Azure: Configure service principal certificate rotation
  • For GCP: Use Workload Identity Federation where possible

Least Privilege permissions

  • Start with zero permissions and add only what's needed
  • Document WHY each permission exists
  • Use permission boundaries (AWS) or conditional access (Azure) to cap permissions
  • Review with IAM Access Analyzer (AWS), Entra permissions (Azure)

Secure storage

  • Never put credentials in prompts or hardcode in agent configuration
  • Use secrets managers (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager)
  • Audit credential access

Monitoring & response

Centralized logging

Important: Logs capture execution, not intent. You'll see what the agent did, not why it decided to do it. This limits investigative depth for AI-specific incidents.

Platform

Primary log source

What to capture (if enabled)

AWS

CloudWatch, CloudTrail

Agent invocations, IAM role assumptions, API calls (when configured)

Azure

Azure Monitor, Entra ID logs

All 3 identity contexts, connector activity (depending on telemetry settings)

GCP

Cloud logging

Service account usage, agent execution (visibility limited to what Google surfaces)

  • Export logs to SIEM
  • Set retention per compliance requirements
  • Create agent-specific log streams/groups
  • Verify logging is actually enabled; don't assume default configurations capture agent activity

Agent-specific alerting

Create alerts for:

  • Permission-denied attempts
  • New resource access (i.e., agent touching new systems)
  • Unusual activity volume
  • After-hours execution (if agents have expected schedules)
  • Privilege escalation attempts

Incident response quick reference

Note: These logs show agent actions if logging was enabled. CloudTrail and Azure Monitor don't automatically show agent-specific invocations—you need to correlate IAM/Entra activity with agent identity.

Platform

First response

Logs to check (if configured)

Escalation

AWS

Revoke agent execution role

CloudWatch, CloudTrail (correlate with agent role ARN)

AWS Support

Azure

Disable agent in Power Platform

All 3 audit trails—agent, maker, users (each may require separate queries)

Microsoft Support

GCP

Revoke SA permissions

Cloud Logging (limited to what Google surfaces; no runtime inspection)

Google Support

  • Document incident response procedures per platform
  • Know that Azure requires checking 3 audit locations
  • Accept GCP infrastructure visibility limits in IR planning
  • Test that your logging actually captures agent activity before you need it for IR

Section 5

Quick Reference

Platform decision matrix

Factor

AWS Bedrock

Azure Copilot Studio

GCP Vertex AI

Identity model

Single (IAM role)

Multiple (2 modes + artifacts)

Single (Service Account)

Complexity

Medium

High

Low

Visibility

Full

Fragmented

Limited

Control

Full

Partial

Limited

Operational Burden

High

Medium

Low

Best For

Regulated industries, full control needs

Enterprise integrations, Microsoft ecosystem

Rapid deployment, managed preference

What to expect from each platform

Companies typically choose agent platforms based on functionality, ecosystem fit, and ease of use, then handle identity security afterward. Here’s what identity management looks like given your platform choice:

bedrock-color

If you're using AWS Bedrock:

  • Expect full infrastructure visibility
  • Plan for IAM role management at scale
  • Leverage existing AWS security patterns
  • Budget time for operational overhead
CopilotStudio_scalable

If you're using Azure Copilot Studio:

  • Expect to manage three identity contexts per agent
  • Plan for fragmented audit trails
  • Audit maker permissions carefully
  • Design connector ownership strategy upfront
vertexai-color

If you're using GCP Vertex AI:

  • Expect limited infrastructure visibility
  • Plan around Google-managed components
  • Avoid default service accounts from day one
  • Accept visibility trade-offs in your IR planning

Incident response cheat sheet

Note: “Agent misbehavior” itself is a unique incident category. Unlike service accounts that fail predictably, agents can behave unexpectedly due to prompt manipulation, model drift, or emergent behavior, not just compromise. Your IR process needs to account for this ambiguity.

AWS: Agent misbehaving

  1. Immediately: Revoke agent execution role (aws iam delete-role-policy)
  2. Investigate: CloudWatch logs for agent, CloudTrail for IAM activity
  3. Contain: Disable any tool integrations (Lambda functions, API endpoints, or other services the agent calls)
  4. Remediate: Review permissions, redeploy with least privilege

Azure: Agent misbehaving

  1. Immediately: Disable agent in Copilot Studio
  2. Investigate: Check ALL THREE audit trails:
    • Agent service principal logs
    • Maker account audit logs
    • User delegation logs (for every user who invoked)
  3. Contain: Disable connectors, revoke maker credentials if needed
  4. Remediate: Review connector identity modes, consider dedicated service accounts

GCP: Agent misbehaving

  1. Immediately: Revoke service account permissions
  2. Investigate: Cloud Logging (note: limited infrastructure visibility)
  3. Contain: If default SA, affects ALL agents using it, disable all
  4. Remediate: Switch to custom SA, one per agent

Identity-specific failure modes

Beyond the platform-specific risks covered above, several failure modes are unique to agent identity:

Delegation chains outliving users: A user grants an agent permission to act on their behalf. The user leaves the organization. The delegation may persist, and the agent continues acting under a departed user’s authority.

Workflow agents bypassing UI controls: Agents invoked via workflow automation may skip the approval flows that humans see. If the UI enforces authorization checks that the API doesn’t, workflow-triggered agents operate under different rules.

Cross-agent privilege inheritance: Agent A has access to System X. Agent A can invoke Agent B. Does Agent B now have access to System X? The answer depends on identity propagation, which varies by platform and configuration.

Version/alias drift (AWS Bedrock): Traffic routed to an older agent version via alias may have different permissions than the current version. Security posture can silently regress.

These are not generic AI risks: they're identity-specific governance gaps that require identity-specific controls.

Section 6

Glossary

Action Group

(AWS) Configuration defining what tools/actions a Bedrock agent can use

Agent Author Authentication

(Azure) Microsoft's term for using the connector creator's credentials

Agent Execution Role

(AWS) The IAM role that a Bedrock agent assumes when it runs

Blast Radius

The scope of resources affected if an identity is compromised

Agent Service Principal

(Azure) The agent's own Entra ID application identity—appears as a third identity artifact

Connector

(Azure) Pre-built integration allowing agents to interact with external services

Custom Service Account

(GCP) User-created, agent-specific service account—recommended for production

Identity Mode

The context under which an action is authenticated (user, maker, or agent)

NHI

Non-Human Identity—service accounts, API keys, and similar machine identities

Prompt Injection

Attack that manipulates agent behavior through crafted input

Reasoning Engine Service Agent

(GCP) Google-managed service account for Vertex AI agents, project-scoped

User Authentication

(Azure) Microsoft's term for using the invoking user's delegated permissions

Summary

bedrock-color

AWS: Your account, your identity.

Full control means full responsibility—map IAM roles, enforce least privilege, own your mistakes.

Black-white

Azure: Multiple identities, one agent.

The flexible authentication model enables enterprise integrations but fragments accountability. Know which authentication mode each connector uses.

vertexai-color

GCP: Managed simplicity, limited visibility

Avoid the default service account trap. Accept that you can’t see inside Google’s infrastructure.

The common thread: AI agents aren’t service accounts. They’re adaptive, unpredictable, and valuable precisely because they don’t follow scripts. Traditional NHI controls assumed predictable behavior. That assumption is now invalid.

What this guide doesn't solve

This guide explains how agent identity works. It doesn’t solve the harder problem: enforcing identity controls inline, at runtime—before actions happen, not after.

Cloud providers optimize for platform correctness, not enterprise accountability. If you wait for them to solve agent identity holistically, you will inherit their blind spots.

The next step is runtime enforcement: identity verification in the moment, across platforms, with the context to make intelligent allow/deny decisions. Most organizations are not architected to do this today.

That’s the work ahead.

This guide reflects platform capabilities as of January 2026. Cloud providers regularly update their services—verify current documentation for implementation details.