AI agents need data boundaries: new VPC Service Controls options

An AI agent can act for a person, call tools and retrieve data from several cloud projects. That accelerates work, but it also means one overly broad permission may be exercised faster and at greater scale than by a single employee. On 15 October, Google Cloud announced new VPC Service Controls capabilities intended to simplify data boundaries in large environments.

The central change is the ability to include an entire Google Cloud folder in a perimeter. Projects and nested folders inherit protection, so a new project placed in the correct hierarchy does not need to be added manually. Ingress and egress rules can also refer to folders and organisations instead of maintaining long lists of individual projects.

Breachroad’s conclusion: this is a useful data-exfiltration control, but it is not a one-switch “AI agent security” feature. A perimeter does not replace IAM, least-privilege tool permissions, prompt controls, approval for risky actions, audit logging or security testing. It should reinforce those measures.

What changes in practice

Google describes several capabilities that replace manual lists with more durable policy:

• folders can be perimeter members, allowing protection to follow the project hierarchy;
• folders and entire organisations can appear in ingress and egress rules;
• a Private Service Connect endpoint for Google APIs can be used as a rule attribute, tying authorisation to a designated private path;
• service patterns in VPC accessible services can limit private-VIP access to selected API URL patterns;
• Violation Analyzer can propose a narrowly scoped policy change after a denial, which an administrator can evaluate in dry-run mode first.

The folder-membership documentation explains that projects later added beneath a protected folder automatically join the same perimeter. Moving a project or folder changes its effective protection, however. Resource hierarchy is no longer just a billing and organisation structure; it becomes part of the security mechanism.

Check each feature’s status separately in the documentation and VPC Service Controls release notes. Folder membership and the use of folders and organisations in rules are generally available, while adjacent capabilities, including automated remediation suggestions, may have a different release stage. Confirm availability in your scope before relying on a feature as a production control.

Why this matters for AI agents

A conventional application usually performs a predictable set of operations. An agent selects its next steps from a goal, context and tool results. It might read a document, call a search service, write a file, start an analytics job and send the result elsewhere. Even where each action is permitted in isolation, an unexpected sequence can exceed the process owner’s intent.

A data perimeter provides a boundary independent of the model’s decision. If an agent or compromised credential tries to send information to a resource outside the allowed area, VPC Service Controls can block a supported flow. This is particularly useful when an account has a formal IAM permission but the request comes from the wrong context or crosses the intended boundary.

VPC Service Controls does not cover every data source and service. An agent may use an external SaaS product, the public internet, an internal API or a tool outside the supported scope. The first step is therefore to map actual flows, not assume that the word “perimeter” covers everything.

Design a boundary for one business process

Start with one business outcome, such as an agent assisting a customer-service team. Record who starts the process, which identity the agent uses, the sources it may read, the tools it may call, where the answer goes and which action requires human approval.

Then group data by the consequence of disclosure. Public help content, internal documentation, customer cases and credentials should not automatically occupy one zone merely because one agent may need them. Separate projects or folders add value only when they express a real policy about ownership and flows.

A practical deployment sequence is:

1. Inventory projects, data, services, agent identities and tools.
2. Define folders that follow data boundaries, not merely team structure.
3. Run the proposed perimeter in dry-run mode and observe legitimate traffic.
4. Evaluate each exception by source, identity, service, method and destination.
5. Enforce policy after required flows are accounted for and denial handling is ready.
6. Monitor project moves and the creation of new integrations and agent tools.

When migrating from explicitly listed projects to folder membership, Google recommends retaining the explicit entries for at least 48 hours to allow resource-hierarchy propagation. That is vendor guidance. The organisation must still design its data groups and approval process around its own risk.

Do not approve a suggested fix automatically

A recommendation from Violation Analyzer may shorten diagnosis, but it remains a security-policy change. Before approving it, verify that the proposal does not expand access to a wider folder, method or data set than intended. Review it with the process owner and test it in dry-run mode.

The worst operational pattern is repeatedly widening a perimeter simply to make an agent “work”. A denial may expose poor integration architecture, an overly broad goal or an uncontrolled tool. The right answer can be a mediation service, a smaller data set or an asynchronous export rather than another policy exception.

Questions for an organisation before launching an agent

• Can the business owner identify data that the agent must never send outside its boundary?
• Does the agent have a non-human identity separate from a person and limited permissions?
• Is it clear which actions are autonomous and which require approval?
• Can logs connect an agent decision to a tool call and data change?
• Does every perimeter exception have an owner, rationale and review date?
• Can the team resolve a denial safely without opening access “temporarily”?

These answers connect cloud architecture with human accountability. Details of the new capabilities and their behaviour come from Google Cloud materials. Treating hierarchy as a data boundary, the exception-review model and the control questions are Breachroad recommendations. Our guide to securing AI and LLM use in business provides wider context, while business, cloud and security teams can design these controls together in our secure AI implementation workshops.