GCP Agent Identity Security Testing After the Auth Manager GA
A platform engineering team at a mid-market SaaS company spent the summer moving its support and ops agents off hardcoded API keys and onto Google Cloud's Agent Identity auth manager. The pitch from the platform side was simple: one managed vault, no more secrets scattered through agent code, every credential tied to a cryptographic identity instead of a shared service account. The security review that followed asked a different question. Not "does the vault work," but "what happens to a live third-party token the moment an agent's runtime is compromised."
That question has a concrete answer as of August 22, 2026, when Google Cloud moved the Agent Identity auth manager and the Agent Identity APIs to general availability. The auth manager is now the supported, production-blessed way for a Google Cloud agent to authenticate to BigQuery, Jira, GitHub, or any other external tool. It replaces a landscape of hardcoded keys and shared service accounts with a centralized broker. That is a real improvement. It is also a new architecture with a blast-radius profile most teams have not scoped a pentest around, because the feature did not exist as a GA product eight weeks ago.
This is a GCP Agent Identity security testing scope guide for that specific mechanism. It is written for CTOs, CISOs, platform engineering leads, and design-review owners who are deciding, right now, whether their GCP-hosted agents are ready for a security assessment that actually tests the broker rather than assuming it away.
Why the Auth Manager GA Changes the Cloud Pentest Scope
Agent Identity itself, the cryptographic, SPIFFE-based identity assigned to each agent, reached general availability back in April 2026. That part of the architecture has had months of production exposure. The auth manager, by contrast, sat in preview from April until it went GA on August 22, alongside the Agent Identity APIs that replace the legacy IAM Connectors API. Two supporting controls, Organization Policy custom constraints and VPC Service Controls integration for the Agent Identity APIs, reached GA eight days earlier, on August 14.
That sequencing matters for a pentest scope. A design review that only checked "is Agent Identity GA" would have answered yes back in the spring and missed that the credential-handling layer underneath it was still a preview feature until three weeks ago. Any organization that piloted agent identity early is now running on a component that has just crossed the line into full support, with a different risk posture than a mature GA product carries.
The auth manager's job is to act as a centralized credentials vault and authentication broker for outbound agent authentication. It stores API keys, OAuth client IDs and secrets, and delegated end-user tokens, and it lets an agent authenticate to a third-party tool using one of three provider types: 3-legged OAuth for user-delegated access, 2-legged OAuth for the agent's own authority, and API keys. Every credential request is itself authenticated using the agent's SPIFFE ID, so access to the vault is governed by IAM rather than by whoever happens to hold a shared key.
For a cloud pentest, the practical shift is this: a credential broker is no longer a hypothetical architecture pattern worth asking about during scoping. It is a named, documented, GA Google Cloud resource with its own API surface, its own audit log stream, and its own failure modes. If your organization has agents calling external tools from GCP, the broker is either already part of your attack surface or about to be, and a pentest that treats "we use Agent Identity" as a single yes/no checkbox will miss the question that actually matters.
Cloud penetration testing for GCP, AWS, and Azure already covers IAM misconfiguration, secrets handling, and workload identity federation as core test areas. A GCP engagement scoped after August 2026 should treat the auth manager as a distinct, named asset inside that secrets-and-credentials test area, not as a footnote to a broader IAM review.
The Broker Model vs. the Identity Model: Why This Is a Different Test
Our earlier guide on what a cloud pentest must prove about AI agent identity security covers the general architecture question across AWS, Azure, and Google Cloud: unique identity, effective permissions, tenant isolation, tool authorization, revocation, and audit correlation. That control matrix still applies, and a GCP-hosted agent using the auth manager should be tested against every row in it.
This article sits one layer beneath that matrix. Agent Identity answers "who is the agent, cryptographically." The auth manager answers a separate question: "where does a live third-party secret physically live while the agent is running, and who or what can reach it." Those are different security properties, and a pentest that only validates the first one has not touched the second.
The distinction matters because Google's own documentation describes two materially different ways an agent can use the auth manager, and it does not present them as a trade-off in one place. In the first path, an agent built on the Agent Development Kit requests a credential directly from the auth manager, and the vault returns that credential to the agent's own process, which then attaches it to the outbound request. In the second path, when the agent identity is used with Agent Gateway alongside Gemini Enterprise, end-user credentials are encrypted by the auth manager and only decrypted at the gateway, so the agent's own code never sees the raw credential at all.
Those two paths produce very different outcomes if an attacker manages to manipulate the agent through a prompt injection, a compromised dependency, or a memory-disclosure bug. In the direct path, a live, usable third-party token sits in the agent's process memory. In the gateway path, there is nothing there for an attacker to take: the credential never crosses into agent-controlled code. Independent architectural analysis published the week of the GA announcement flagged this exact gap, noting that most quickstart documentation shows the direct path because it has fewer moving parts, while the gateway path is the one that actually matches an agent's realistic threat model.
For a buyer commissioning a pentest, this means one scoping question now sits ahead of almost everything else: which path does each in-scope agent actually use, and was that a deliberate security decision or an artifact of following the fastest tutorial?
Two Trust Architectures Under One Feature Name
Google is not the only vendor answering the "who is the agent, and on whose authority does it call the tool" question, and the comparison is useful for scoping because it clarifies what the auth manager does and does not solve on its own.
Google's answer is a broker that holds delegated secrets on the agent's behalf, authenticated by the agent's SPIFFE identity and access tokens cryptographically bound to that agent's X.509 certificate. Microsoft's answer, through Entra Agent ID, is a directory object carrying policy, closer to how enterprise identity governance already treats human and service principals. The Model Context Protocol community's answer is a federated token exchange under RFC 8693, where delegation is a property of the token itself rather than a configuration choice made when a developer sets up an auth provider.
These are not interchangeable. In the broker model, the difference between an agent acting as itself and an agent acting on a user's behalf is which auth provider type was configured in the console. The agent code and the tool call can look identical either way; only the audit record differs, and only if someone knows to check it. In a token-exchange model, that distinction is a structural property of the token that a downstream resource server can verify without knowing anything about how the caller was set up.
If your agents also route through MCP servers to reach tools, this configuration-versus-protocol distinction is exactly the kind of trust-boundary question our guide to MCP security testing before production is built to test: identity at every hop, token audience and scope, and whether user context survives the full path from agent to downstream API. An auth-manager pentest and an MCP pentest overlap where an agent uses the broker to authenticate to an MCP server; scoping should make clear which engagement covers that seam.
GCP Agent Identity Security Testing: Risk Register for the Auth Manager
The table below turns the architecture into testable line items. It is scoped narrowly to the auth manager and the Agent Identity APIs, on top of whatever broader IAM, storage, and network testing a standard GCP engagement already covers.
| Risk area | What the design should enforce | What the pentest should prove | Evidence expected |
|---|---|---|---|
| Direct vs. gateway credential path | High-impact and regulated-data agents should never hold raw third-party secrets in process memory | Which path each in-scope agent actually uses, and whether that was a documented decision | Architecture diagram, provider configuration, code-level credential-handling trace |
| Perimeter sequencing | The Agent Identity APIs sit behind a VPC Service Controls perimeter before broad production use | A stolen caller token cannot pull secrets to an attacker-controlled project | Perimeter configuration, ingress/egress rule test results |
| Organization Policy coverage | Custom constraints restrict how auth providers and agent identity resources are created | Provider creation is restricted to approved patterns, not left to default project permissions | Org Policy configuration and negative-test results against unapproved creation attempts |
| Granular SPIFFE-ID scoping | Each agent principal reaches only the auth providers it has been explicitly granted | A given agent cannot enumerate or request credentials for a provider outside its assigned scope | IAM allow-policy review, cross-agent negative tests |
| Certificate and token binding | Access tokens remain cryptographically bound to the agent's X.509 certificate; the injection escape hatch stays unused | A stolen token cannot be replayed outside the runtime holding the matching private key | Token-binding verification, escape-hatch configuration check |
| Legacy Connectors API migration | Any auth providers created during the preview period are fully migrated, not left dual-running | No auth provider or credential path still resolves through the deprecated Connectors API | Migration inventory, API call audit |
| Audit correlation across the boundary | Cloud Audit Logs for the Agent Identity and Agent Identity Credentials APIs correlate with the downstream tool's own logs | An investigator can reconstruct which agent requested a credential, when, and what the tool did with it, without vendor-log gaps | Correlated log sample across at least one first-party and one third-party tool call |
| Delegation clarity | 3-legged (user-delegated) and 2-legged (agent's own authority) provider types are not interchangeable for the same tool call | A workflow requiring user-delegated authority cannot silently fall back to the agent's own, broader authority | Provider-type configuration review, role-by-role test results |
This register is deliberately narrow. It assumes the broader identity, tenant-isolation, and tool-authorization questions from our general agent identity guide are already in scope, and adds the broker-specific gaps that only exist because this particular mechanism just went GA.
Evidence a GCP Agent Identity Pentest Must Produce
A useful engagement report on this scope should let a CTO or CISO answer, in writing, whether the organization's Agent Identity deployment is production-ready. That means the deliverable should include:
- A credential-path inventory naming every in-scope agent and which path, direct ADK or Agent Gateway, it uses to reach each external tool.
- A provider-type map showing which tools use 3-legged OAuth, 2-legged OAuth, or API key providers, and whether that choice matches the intended delegation model for each workflow.
- Perimeter and policy verification confirming VPC Service Controls and Organization Policy custom constraints are actually applied to the Agent Identity APIs in the tested environment, not merely available.
- Negative test results showing that an agent scoped to one auth provider cannot reach another agent's provider or credential.
- Migration status for any auth providers or agent identities created before the August 22 GA, confirming they no longer depend on the deprecated Connectors API.
- A correlated audit trail demonstrating that a credential request, its use against a third-party tool, and that tool's own log entry can be reconstructed as one event chain.
This evidence set is what turns "we adopted Agent Identity" into something a board, an enterprise customer, or an auditor can actually rely on. For teams building a broader compliance narrative around AI system evidence, our guide to mapping AI pentest findings to the NIST AI RMF explains how this kind of technical evidence slots into Govern, Map, Measure, and Manage documentation for SOC 2 or enterprise vendor review.
Framework Mapping
Framework mapping organizes evidence; it does not replace an architecture-specific test.
| Framework or control | Relevance to the auth manager | Expected evidence |
|---|---|---|
| OWASP Top 10 for Agentic Applications 2026, ASI02: Tool Misuse & Exploitation | A legitimate credential is used to call a tool outside its intended business purpose | Per-provider allow/deny results, tool-call boundary tests |
| OWASP Top 10 for Agentic Applications 2026, ASI03: Identity & Privilege Abuse | An agent's SPIFFE identity or its delegated credentials are used beyond intended scope | Cross-agent negative tests, effective-permission review against granted auth providers |
| OWASP Top 10 for Agentic Applications 2026, ASI08: Cascading Failures | A single compromised credential path amplifies into broader downstream impact | Chain trace showing blast radius under the direct path versus the gateway path |
| NIST SP 800-53 Rev. 5, AC-3 | Enforces approved logical authorizations for processes acting on a user's or system's behalf | Decisions verified at the auth-provider, IAM, and downstream-tool layers |
| NIST SP 800-53 Rev. 5, AC-6 | Applies least privilege to non-human principals, including agent identities | Narrow, per-agent SPIFFE scoping rather than shared or over-broad provider access |
| NIST AI RMF | Structures governance, context, measurement, and treatment of the credential-broker risk | Documented risk-register entry for the broker as a single, high-value asset, not a footnote |
Mapping a finding to ASI03 or AC-6 does not certify the deployment as secure. It gives your governance committee and your auditor a common reference point for what was tested and why it matters.
What Leadership Should Decide Before Production
Before approving production use of Agent Identity auth manager for any workflow touching regulated or customer data, leadership should require written answers to these questions:
- Path decision: For each in-scope agent, does it use the direct ADK path or the Agent Gateway path, and was that a deliberate risk decision or a default carried over from a tutorial?
- Perimeter status: Are the Agent Identity API and Agent Identity Credentials API inside a VPC Service Controls perimeter, and has that perimeter been tested against a stolen-token scenario?
- Policy status: Do Organization Policy custom constraints exist for auth-provider creation, and were they written before or after the first provider went live?
- Migration status: Has every auth provider created during the preview period been fully migrated off the legacy Connectors API?
- Delegation clarity: For every tool call that should run under a specific user's authority, is that enforced by provider type, or could the same call also succeed under the agent's own broader authority?
- Audit reconstruction: Can your team, today, reconstruct which agent requested a given credential, when, and what happened at the downstream tool, without manual log correlation across systems with different retention windows?
A launch decision resting on "we use Agent Identity, it's GA" is not sufficient. The GA milestone means Google now supports the feature in production; it does not mean your specific deployment has been tested against the failure modes that come with centralizing secrets behind a broker that a non-deterministic process can be manipulated into calling.
A Hypothetical Scenario: The Broker Is Secure, the Path Choice Was Not
Consider a hypothetical logistics SaaS company that deployed an internal ops agent on Vertex AI Agent Builder in the spring, before the auth manager reached GA. The team followed the documented quickstart, which used the direct ADK path: the agent requests a GitHub API credential from the auth manager and attaches it to outbound requests itself. The setup worked well in the pilot, and it was carried forward unchanged into production once the feature graduated to GA in August.
The agent's job includes reading internal tickets that occasionally contain content from external vendors, some of it lightly formatted, none of it treated as untrusted. A pentest scoped narrowly to "does the vault work" would confirm that credentials are stored correctly, access is governed by IAM, and tokens are certificate-bound. All of that is true and none of it is the actual exposure.
The exposure is architectural: because the agent uses the direct path, a successful prompt injection through a vendor ticket that manipulates the agent into an unintended tool call would place a live GitHub token in the agent's own process memory, reachable by whatever manipulated the agent in the first place. The auth manager did its job. The path decision made underneath it did not match the agent's actual exposure to untrusted input.
The remediation is not to distrust Agent Identity. It is to move the workflow behind Agent Gateway so the agent process never holds the raw credential, and to make that path choice an explicit, reviewed decision for every future agent rather than whatever the fastest quickstart happened to show. This scenario is illustrative only. It is not a client engagement or a working exploit sequence.
Scope the Test Around the Broker, Not the Demo
A demo that shows an agent successfully authenticating to BigQuery or GitHub through the auth manager proves the happy path works. It does not prove the credential-handling architecture matches the agent's actual exposure to untrusted input, that the perimeter and policy controls that shipped days before GA are actually applied in your environment, or that a compromised agent process cannot walk away with a live third-party token.
Pentest Testing Corp's cloud penetration testing service covers IAM, secrets and credentials management, and shared-responsibility gaps across AWS, Azure, and Google Cloud, and an engagement scoped after August 2026 should treat the Agent Identity auth manager as a named asset inside that scope for any GCP-hosted agent calling external tools. Where the assessment also needs to cover model behavior, prompt injection resistance, or broader agentic workflow risk beyond the credential layer, combine it with AI penetration testing. For agents making consequential decisions with financial or regulated data, our guide to financial services AI agent security covers the workflow-level authority questions that sit above the identity and credential layer this article addresses.
The goal is a bounded engagement that tells you which path your agents actually use, whether the perimeter controls that just went GA are actually in force, and what changes before the next agent goes into production under the same broker.
Frequently Asked Questions About GCP Agent Identity Security Testing
What is the difference between Agent Identity and the Agent Identity auth manager?
Agent Identity is the cryptographic, SPIFFE-based identity assigned to each agent; it reached general availability in April 2026. The auth manager is a separate component, a centralized credentials vault and authentication broker that uses that identity to let agents authenticate to external tools; it reached general availability on August 22, 2026, alongside the Agent Identity APIs.
Does using the auth manager automatically make agent credentials secure?
No. The auth manager removes hardcoded secrets from agent code and governs access through IAM, which is a real improvement over the alternative. Whether a specific deployment is secure still depends on which credential path each agent uses, whether perimeter and policy controls are actually applied, and whether delegation is scoped correctly for each tool.
What is the difference between the direct ADK path and the Agent Gateway path?
In the direct path, an agent built on the Agent Development Kit requests a credential from the auth manager and the raw credential is returned to the agent's own process. In the Agent Gateway path, credentials are decrypted only at the gateway, so the agent's code never accesses the raw value. The gateway path has a smaller blast radius if the agent is compromised through prompt injection or a dependency issue.
Should every agent use Agent Gateway instead of the direct path?
Not necessarily, but the choice should be deliberate. Agents with limited exposure to untrusted input and low-impact tool access may reasonably use the direct path. Agents that process external or untrusted content and hold credentials for regulated or high-impact tools should generally be routed through Agent Gateway so a compromised agent process cannot retrieve a live third-party secret.
How does the auth manager relate to VPC Service Controls?
The Agent Identity API and Agent Identity Credentials API can be added to a VPC Service Controls perimeter, with support for using agent identities in ingress and egress rules. This control reached general availability on August 14, 2026, eight days before the auth manager itself. A pentest should verify the perimeter is actually configured, not merely available.
What happened to organizations that adopted Agent Identity during the preview period?
Any auth providers or agent identities created while the auth manager was in preview were carried forward, but the legacy IAM Connectors API that some early integrations depended on is being replaced by the Agent Identity APIs and will not reach general availability itself. Organizations in this position should treat the transition as a planned migration, not a passive cutover, and verify no credential path still resolves through the deprecated API.
Does this replace the need for broader AI agent identity testing across AWS and Azure?
No. This guide is scoped specifically to the GCP auth manager mechanism that just went GA. Broader questions about tenant isolation, effective permissions, delegation, and revocation across AWS, Azure, and Google Cloud are covered in our guide to AI agent identity security and what a cloud pentest must prove.
How is this different from an MCP security assessment?
An MCP security assessment tests the trust boundary between an agent, an MCP server, and the tools it exposes, including token audience, scope, and user-context propagation. An Agent Identity auth manager assessment tests how a GCP agent acquires and holds the credentials it uses, whether those credentials reach MCP servers or other tools directly. Where an agent uses the auth manager to authenticate to an MCP server, both assessments are relevant and should be scoped together.
