Why the perimeter question comes first
Bank security reviews reach the same question early: what prevents the agent from moving data somewhere it should not? The question is more urgent than it is for a conventional application because model behaviour is not determined only by developer-written code. It is also influenced by retrieved text, including content placed by an attacker or careless insider. A conventional application's access paths are fixed at build time. An agent chooses among available tools at run time. The perimeter must remain effective even when the model chooses badly.
VPC Service Controls and workload identity federation are therefore not late-stage hardening. They are prerequisites. Retrofitting them often exposes earlier design errors: one service account shared across environments, or a retrieval index created outside the intended boundary. Those choices have to be undone rather than wrapped with another control.
VPC service controls fundamentals for an agent estate
VPC Service Controls establishes a service perimeter around selected Google Cloud projects and supported services. A valid IAM credential alone is not enough to cross that boundary. This matters because IAM and the perimeter answer different questions. IAM asks whether an identity may call an API. VPC Service Controls asks whether an otherwise valid call may use this path and move data to this destination. The second check closes an important gap in an IAM-only design.
A typical perimeter contains Agent Runtime, formerly Agent Engine, plus supported BigQuery, AlloyDB and Cloud Storage resources. The project must enter the service perimeter before the agent is deployed. Agent Runtime reaches external services through a deliberately configured proxy path; a VPC Service Controls rule alone is not a generic third-party network route.
Perimeter bridges allow access between perimeters for specified services. They may be needed when an agent estate consumes a shared enterprise data platform owned by another unit. Scope them to named services and projects on each side. Treat a bridge as a standing cross-boundary commitment that receives periodic review, not as a one-off build approval.
The two-tier identity model, human entitlement meets workload identity
The next problem is identity. The runtime service account touches BigQuery and AlloyDB, but a relationship manager must see only the assigned client book. The human and the workload are different identities. Conflating them either makes the service account unusably narrow or makes it dangerously broad and leaves human entitlement to application filtering.
A two-tier model separates the questions. The workload identity is scoped to the business service it operates. Each tool query also carries the human entitlement resolved from the corporate identity provider. Database row policies enforce that entitlement. The workload credential answers whether this service may reach the database at all. The signed human claim determines which rows this request may see.
The entitlement must originate in a signed token issued when the person authenticates. The model and its tool arguments must not be able to set it. Test this explicitly: use a crafted prompt to claim another relationship manager's identity and confirm that the row policy rejects the request. This verifies the control rather than its documentation.
Workload identity federation replacing service account keys
The most consequential identity decision is to refuse long-lived service-account keys. Use workload identity federation wherever a credential crosses a trust boundary: from on-premises, another cloud, or a delivery pipeline. A downloaded JSON key is a bearer credential without a default expiry or binding to its intended workload. It can be committed to source control, embedded in an image or left on a laptop.
Federation replaces that secret with a trust relationship. Google Cloud accepts a token from a configured external identity provider and exchanges it for a short-lived, scoped Google credential. The external source may be a corporate identity provider, Kubernetes service account or CI platform using OIDC. No long-lived key needs to be stored. If a token is intercepted, its scope and lifetime limit the damage.
Apply the pattern in three places. First, give each Agent Runtime deployment a dedicated service account and federate callers that begin outside Google Cloud. Second, broker credentials for external tools through a secrets and identity layer. Third, let the delivery pipeline authenticate from its own OIDC identity instead of a stored deployment key.
The tool-calling attack surface
Tool calls become partially attacker-influenced whenever the model reads an untrusted document, email or web page. Embedded text can redirect model behaviour. The control objective is therefore stronger than detecting every injection. Even if an injection persuades the model to attempt an unauthorised action, the identity and network layers must block the action.
A narrow tool can read one trade by a validated identifier under an identity restricted to that table and access pattern. It cannot exfiltrate the entire dataset because its credential cannot perform that action. A generic “run this SQL query” tool creates a much larger surface. A successful injection inherits the breadth of the tool's access. Prompt instructions are not a substitute for capability that does not exist.
Before production, assume the model is fully compromised and will attempt every action the interface allows. Is the worst case tolerable? If not, narrow the tool, tighten the IAM binding or add a network control. Do not answer with a stronger prompt.
Cmek across the estate
Customer-managed encryption keys give the bank control over the key material protecting data at rest. This matters for revocation and evidence. Removing access to a Cloud KMS key can make protected data unavailable without waiting for an IAM unwind across every consumer. Cloud KMS also records key access independently of application logs. That separate trail helps an incident investigation when application telemetry is incomplete.
Key rotation should follow the institution's cryptographic policy and support emergency rotation. Test the process rather than merely documenting it. A rotation that breaks a downstream service's ability to read existing data creates a self-inflicted outage.
Security support is feature-specific. Agent Runtime supports VPC Service Controls, CMEK and data residency for data at rest. Agent Platform Sessions and Agent Platform Memory Bank support those controls at regional and multi-regional endpoints. Their global endpoints cannot use CMEK. Example Store does not currently support VPC Service Controls, CMEK or at-rest data residency.
| Agent Platform feature | VPC service controls | Cmek | At-rest data residency |
|---|---|---|---|
| Agent Runtime | yes | yes | yes |
| Agent Platform Sessions | yes | yes, except global endpoint | yes; select location deliberately |
| Agent Platform Memory Bank | yes | yes, except global endpoint | yes; model processing follows endpoint location |
| Example Store | no | no | no |
Egress rules for the small number of external calls
An agent estate usually needs a small number of external calls. Keep the list explicit and reviewed so that individually reasonable exceptions do not make the perimeter porous. Give each market-data feed, screening API or communication channel a named egress rule and owner. Review the highest data classification the path could carry, not only what it is intended to carry. Reconfirm the business need on the institution's access-review cadence.
Route outbound calls through an audited proxy rather than letting each tool open its own connection. The security team gains one place for logging, rate limits and content inspection. A payload-size rule, for example, can catch a serialization defect that attaches retrieved context to a notification instead of the intended summary. This is a useful pre-production test case even when no such incident has occurred.
| Control | Enforces | Failure mode it prevents |
|---|---|---|
| VPC Service Controls perimeter | Context-based boundary for supported services | Legitimate credential used to move protected data across the perimeter |
| Workload identity federation | Short-lived, scoped credentials | Long-lived key leakage with unbounded blast radius |
| Narrow tool scoping | Credential-level action limits | Prompt injection escalating into broad data access |
| CMEK | Key-level control over data at rest | Slow, incomplete access revocation during an incident |
| Audited egress proxy | Centralised logging and inspection | Silent exfiltration through a legitimate-looking tool call |
Sensitive data protection as a second line inside the perimeter
VPC Service Controls and workload identity determine where data can move and who can move it. They do not identify the data itself. A tax identifier may still sit inside an unclassified case note. Sensitive Data Protection can scan for national identifiers, card numbers and institution-specific patterns. Use it at two points: before content enters the retrieval corpus and before an answer reaches a client-facing channel.
Scan each document before chunking and embedding. This can find an account number pasted into a free-text note that later enters retrieval. Tag the sensitive span so retrieval and generation can act on it. Depending on classification and entitlement, mask the span or exclude its chunk pending review. Avoid a design that only creates an unmanaged backlog of flagged documents.
Scan the drafted response again before it leaves for a client-facing channel. This can catch sensitive data admitted through a gap in retrieval or structured-memory controls. The scan is a second, independent check, not a replacement for entitlement enforcement. On its own it prevents only the visible disclosure, not the underlying access violation.
Failure modes
The first failure mode is perimeter scope creep. A sound launch boundary gradually absorbs an evaluation project, then an experimentation sandbox, without revisiting its data assumptions. Express membership as reviewed infrastructure code. Do not leave it as an ad hoc console change.
The second is a federation rule with a broad trust condition. Trusting any token from an external provider widens the boundary to every workload that provider can vouch for. Add attribute conditions for the expected service and environment. In a controlled review, attempt authentication as a different workload under the same provider and confirm rejection.
The third is assuming uniform CMEK coverage. A regional Runtime, Sessions or Memory Bank design may use CMEK while a global Sessions or Memory Bank endpoint cannot. Example Store lacks the control in the current service matrix. Organization Policy can enforce supported resources, but architecture review must also reject unsupported feature-location combinations.
Worked example, securing a cross-border advisory agent
The worked design assumes a wealth-management business operating across three jurisdictions and one advisory-support agent used by relationship managers in all three. Client data must remain inside its jurisdiction, reflecting both local obligations and booking-model segregation between entities.
The design uses three separate perimeters, one for each jurisdiction. Each contains regional BigQuery, AlloyDB and Cloud Storage resources. A shared ADK codebase is deployed as three Agent Runtime instances, and no runtime identity is valid across more than one perimeter. The relationship manager's signed jurisdiction claim routes the request to the local instance. No bridge exists because the scenario has no legitimate cross-jurisdiction data path.
The only shared component is a global market-data feed with no client data. Each perimeter receives an identical proxy policy rather than a bridge. Payload limits, destination controls and content inspection prevent that dependency from becoming an unreviewed client-data path.
Architectural review alone does not verify the design. An independent team should try to retrieve a client from one jurisdiction through a session in another. Test direct tool manipulation and injection embedded in retrieved content, then confirm denial in the VPC Service Controls audit logs. Keep those attacks as a regression library and rerun them whenever perimeter configuration changes. The worked scenario uses twelve launch cases, but the institution should derive its own library from the actual tools and data paths.
Build the boundary from a dependency inventory
Perimeter design should start with data movement, not a list of cloud projects. For each agent capability, enumerate every managed API, storage location, runtime, build path, logging sink, key and external dependency. Mark the data classification entering and leaving each edge. This exercise finds hidden paths such as an evaluation export or a build job that reads a protected artifact from outside the intended context.
The inventory should distinguish a supported service from an unsupported feature within a product family. Agent Runtime supports VPC Service Controls, CMEK and at-rest data residency. Regional and multi-regional Sessions and Memory Bank support those controls, while their global endpoints cannot use CMEK. Example Store lacks all three in the current matrix. A perimeter diagram that labels all of them “Agent Platform” hides a material design difference.
Assign every dependency one of four treatments: inside the perimeter, approved through ingress, approved through egress, or prohibited. External destinations belong behind the audited proxy. Unsupported optional features should be removed or replaced with a controlled store. A design is incomplete when a dependency remains “to be confirmed.”
Separate ingress, egress and perimeter bridges
These mechanisms solve different trust problems. Ingress policy permits a named source context to reach protected resources. Egress policy constrains movement from a protected context to a named destination. A bridge connects resources across two perimeters and creates a continuing relationship between them. None is a generic allow rule.
Each rule should name source, destination, service, identity and business purpose. Temporary rules need an expiry. Avoid broad access levels that admit an entire network or identity population when one workload needs one service. Review both directions of a bridge because its existence can change assumptions in two estates.
Route design also affects evidence. A denied VPC Service Controls request produces a platform violation record. The external proxy must add destination, payload class, policy decision and response outcome. Join those records through a trace or request identifier where possible. A boundary is governable only when every permitted crossing and every denied attempt can be explained.
Treat build, evaluation and support paths as production paths
The runtime is not the only principal that touches protected artifacts. Delivery pipelines upload packages. Evaluation jobs read representative data. Support engineers inspect traces. Key-rotation automation calls Cloud KMS. If those paths sit outside the boundary model, the production perimeter can be strong while its supporting lifecycle remains weak.
Federate the delivery identity and restrict it to approved repository, branch, environment and workflow attributes. Deploy immutable digests rather than mutable tags. Evaluation should use a dedicated identity with no production write authority. Support access should use a named, time-bound role and retain the reason and reviewed actions.
Break-glass access deserves a rehearsal. Confirm that the approver can grant it, the operator can reach only intended resources, monitoring alerts immediately and access expires without manual cleanup. Then verify the record is sufficient for post-event review. A procedure that has never been executed is a hypothesis.
Design the denial and incident path
Perimeter violations are signals, not merely noisy logs. Classify them into configuration error, expired entitlement, unexpected workload, prohibited destination and suspected compromise. Each class needs a response owner. Blocking without triage can leave a legitimate customer journey unavailable; allowing retries can create a flood that hides the original event.
The agent should fail closed for protected data. It may offer a non-sensitive fallback when one has been approved, but it must not reroute around the perimeter. A failed external screening call, for example, can route to manual review. It cannot be replaced with an unapproved public endpoint.
An incident playbook should link the cloud violation, workload identity, tool call and affected session. Revoke the narrowest credential or grant that stops the path. If the event indicates a configuration defect, hold further deployments and test every environment for the same drift. If client data may have crossed an approved proxy incorrectly, use proxy logs and payload hashes to determine scope.
After remediation, rerun the exact denied or escaped path as a regression test. Record the policy and infrastructure versions. The lesson should become executable evidence, not a paragraph in an incident report. This converts perimeter operations into a growing control library.
Detect drift before an exception becomes architecture
Express service-perimeter membership, access levels, ingress, egress, bridges, service accounts and key bindings as reviewed configuration. Compare deployed state with that source on a schedule. Alert on an unmanaged console change and either reverse it or bring it through the exception process.
Drift reporting should emphasise consequences. “One policy changed” says little. “A test workload can now reach a production dataset” identifies exposure. Run synthetic positive and negative calls after material changes. The positive call confirms that the approved journey still works. The negative call confirms that an adjacent identity or destination remains denied.
Exceptions should carry owner, reason, data class, compensating control, approval and expiry. Reviewers should see the cumulative exception set when approving a new one. Ten narrow exceptions can collectively create a broad path that no single request disclosed.
The secure estate is the verified deployed graph, not the approved diagram. Continuous comparison, synthetic tests and expiring exceptions keep those two objects aligned.
Use a minimum viable perimeter for the first slice
The first production slice should be small enough that every crossing is understood. Select one journey, one runtime identity, the minimum supported data services and no optional feature that lacks required controls. Add one external dependency only when the journey cannot operate without it. This creates a boundary that an independent reviewer can test end to end.
Do not confuse a small perimeter with weak governance. It should already include federated delivery, protected evidence, key operations, negative tests and incident ownership. What remains small is the business and dependency scope. Scaling then becomes a sequence of explicit boundary changes rather than a large launch followed by discovery.
Before admitting another agent, compare its identities, data classes, locations, tools and egress with the existing slice. Shared controls can be reused when their assumptions match. A different jurisdiction or materially broader authority may deserve another perimeter. Reuse the control pattern freely; merge trust domains only with evidence.
Notes for practitioners
Design the perimeter before a prototype leaves the sandbox. Retrofitting often means undoing architecture rather than wrapping it. Refuse long-lived service-account keys and federate credentials that cross a trust boundary. Narrow the attribute conditions enough that a controlled test can prove an unintended workload is rejected.
Scope every tool so that its worst possible action is tolerable even after a successful injection. Treat perimeter membership, federation conditions and CMEK coverage as controls that decay through accumulated exceptions. Use automated policy to arrest that decay. Finally, require independent adversarial testing before production approval. Confidence from the design team is not evidence that the boundary holds under attack.
Perimeter acceptance matrix
| Scenario | Expected identity outcome | Expected perimeter outcome | Evidence |
|---|---|---|---|
| approved workload, approved resource | short-lived identity accepted | request allowed | principal, access level and resource |
| approved workload, external resource | identity remains valid | exfiltration path denied | VPC SC violation record |
| developer laptop without access level | user sign-in succeeds | protected API denied | caller context and denial reason |
| compromised token from another context | token may parse | context policy denies | token subject plus context mismatch |
| emergency access | named break-glass identity | time-bound exception only | approval, expiry and reviewed actions |
A valid token is not sufficient authority. The perimeter evaluates context as well as identity. Break-glass access must expire automatically. Every denied test is part of the release evidence, not a configuration inconvenience.
Platform references
- Google Cloud, VPC Service Controls overview, including the distinction between IAM and context-based perimeter controls and the documented limitations for unsupported services.
- Google Cloud, Workload Identity Federation, including token exchange, attribute mapping and attribute conditions.
- Google Cloud, Sensitive Data Protection for discovery, classification and de-identification controls.
- Google Cloud, Customer-managed encryption keys for service-specific CMEK coverage and operating guidance.
- Google Cloud, Agent Runtime for the current feature-level enterprise security matrix.
- Google Cloud, supported agent locations, including the CMEK limitation for global Sessions and Memory Bank.
- Google Cloud, VPC Service Controls with Agent Platform, including deployment-order and egress limitations.
VPC Service Controls protects supported Google-managed service paths; it is not a general firewall for every third-party call or every form of metadata movement. The supported-products and limitations pages must therefore be part of the design review for the exact services selected.