Google Cloud's Agent Identity auth manager went GA on August 22, 2026. It's a real improvement: instead of hardcoded API keys scattered across agent code, you get a centralized vault that hands out credentials based on an agent's SPIFFE identity, governed by IAM.
But "we use the auth manager" tells you almost nothing about your actual exposure if one of your agents gets compromised. What matters is a configuration detail that's easy to miss because it doesn't show up as a warning anywhere: which credential path your agent takes to get that secret in the first place.
This post is a short, practical guide to identifying that path in your own deployment, and why the answer changes what a compromised agent can actually do.
Two paths, same happy-path outcome
Google's docs describe two ways an agent authenticates to an external tool through the auth manager.
Direct ADK path. An agent built on the Agent Development Kit calls the auth manager, requests a credential for a configured provider, and gets the raw value back directly into its own process. The agent code then attaches that credential to its outbound request.
Agent Gateway path. When the agent runs behind Agent Gateway (paired with Gemini Enterprise), the credential is encrypted by the auth manager and decrypted only at the gateway. The agent's own process constructs the tool call, but the raw secret never lands in agent-controlled memory.
In a demo, these look identical. Same BigQuery query, same GitHub API call, same result. The difference only shows up when something goes wrong.
Why the difference matters
If an agent is manipulated through prompt injection in ingested content, a compromised dependency, or a memory-disclosure bug, the direct path means there's a live, usable third-party token sitting in that process's memory. Whatever just took over the process can read it and use it. The gateway path removes that target entirely: there's no raw credential in the agent's memory space to steal.
This is the same "principle of least exposure" argument you'd make for any secrets-handling design, just applied to a component that's three weeks old as a GA product. Most quickstart tutorials default to the direct path because it has fewer moving pieces to wire up. That's a reasonable default for a proof of concept. It's a less reasonable default for a production agent that processes external or untrusted content.
How to actually check which path you're on
A few places to look, roughly in order of reliability:
1. Provider configuration in the console or Terraform. Check how each auth provider is set up. If your agent is registered directly against AuthorizedUserCredential or provider objects without an Agent Gateway resource in front of it, and your outbound calls originate from your own ADK runtime, you're on the direct path.
2. Trace the credential retrieval call in code. Look for where your agent code calls the credential-fetch method against the auth manager (this typically shows up as an explicit SDK call in your tool-invocation logic, not something hidden in a framework default). If your own function receives the decrypted value and constructs the header itself, that's the direct path. If instead your agent hands off a scoped request to a gateway component and never sees the token, that's the gateway path.
3. Audit log inspection. Cloud Audit Logs for the Agent Identity Credentials API will show credential requests. Correlate the requesting principal (the agent's SPIFFE identity) against whether the corresponding tool call originates from the agent's own compute environment or from a gateway service identity. If the tool call and the credential request trace back to the same runtime, you're direct. If the gateway's identity shows up as an intermediary, you're gated.
4. Ask "what's in memory if I dump this process?" This is the test that actually matters and the one worth building into your pre-production checklist: if you paused the agent's process mid-execution during a live tool call, would a raw, usable third-party credential be sitting in memory? If yes, you're on the direct path, whether or not anyone configured it that way on purpose.
None of this requires exotic tooling. It requires someone deliberately checking, because the failure mode here isn't a misconfiguration that throws an error. It's a working system that happens to have a wider blast radius than anyone decided on.
What to do with the answer
If an agent only touches low-sensitivity tools and has no meaningful exposure to untrusted input, the direct path is a defensible choice. Fewer moving parts, easier to debug, lower latency.
If an agent processes external content of any kind, tickets, emails, scraped pages, uploaded files, and holds credentials for anything regulated or high-impact (financial systems, source control, customer data stores), route it behind Agent Gateway. The migration is a configuration change, not a rewrite: you're changing how the agent acquires the credential, not what it does with the tool once it has one.
Two other things worth checking while you're in there, since they went GA in the same window and get missed for the same reason:
- VPC Service Controls perimeter status. The Agent Identity and Agent Identity Credentials APIs can sit inside a VPC-SC perimeter (GA August 14). Available and configured are different states. Confirm the perimeter is actually applied in your environment, not just eligible to be.
- Legacy Connectors API migration. If you set up any auth providers during the preview window (April–August), verify none of them still resolve through the deprecated IAM Connectors API. That migration doesn't happen automatically.
The business side of this
If you're the one implementing this, it's worth being able to answer a non-technical question in one sentence when your security or compliance team asks: for each agent handling sensitive data, does a compromise leak a live secret, or not? That's ultimately what the path decision determines, and it's the finding that shows up first in a scoped assessment of this component.
A cloud pentest scoped to cover this properly won't just check that the vault stores credentials correctly; it'll trace whether the path you're actually running matches the sensitivity of what the agent touches, verify the perimeter controls are enforced rather than merely available, and confirm nothing's still limping along on the deprecated Connectors API. If you want the fuller architecture and risk-register breakdown behind this, including the framework mapping to OWASP's Agentic Top 10 and NIST 800-53, it's covered in the full write-up on GCP Agent Identity security testing.
