- Home
- The Thinking Wire
- The Agent Perimeter Got Specific: MCP-Attribute Rules and Session Recording Shipped
The Agent Perimeter Got Specific: MCP-Attribute Rules and Session Recording Shipped
In May we mapped the containment-vendor convergence: a set of security vendors building toward agent-aware perimeters without coordinating, all pointing the same direction. That post argued the pattern was real and directional. It could not yet point at a config field. As of early July 2026, it can. Google’s VPC Service Controls now accepts agent identities as IAM principals inside ingress and egress rules. HashiCorp Boundary reached 1.0 with session recording. The abstraction became a setting you enable.
The convergence is settled, so this is not the place to re-argue it. What matters now is a split that was not visible in May. Agent governance is bifurcating into two layers that require separate controls. The identity layer answers who the agent is. The network layer answers where its data is allowed to flow. We wrote earlier about network identity as the agent sandbox; the July releases turn that thesis into two distinct enforcement points, and you now need both. IAM alone cannot stop an injected agent from exfiltrating to an external webhook. The agent’s credentials are valid. The destination is the problem.
The identity layer became addressable at the perimeter
VPC Service Controls historically wrapped a set of Google Cloud resources in a boundary and controlled which principals could cross it. The July update lets an agent identity be one of those principals, either as a single identity or as a PrincipalSet, inside ingress and egress rules. That sounds incremental. It is not.
The consequence is network-perimeter revocation. Before, if an agent was compromised, your fastest lever was IAM: strip its roles and hope every downstream system re-checked permissions before the agent finished its current task. Now you can pull a compromised agent out at the perimeter itself. The boundary stops recognizing it as an authorized crosser, regardless of what IAM still says mid-flight. For a nonhuman identity that can issue thousands of operations per minute, the difference between “permissions revoked, propagating” and “blocked at the wall” is the difference between an incident and a near miss.
Mercado Libre put the operational read plainly. “VPC Service Controls serve as an essential, foundational layer, ensuring all our data remains protected,” said Juan Pablo Boschi. Foundational is the right word. The perimeter is where you want the last line, because it does not depend on every service downstream behaving correctly under pressure.
The network layer now reads MCP attributes
The second primitive is the one that changes how you write policy. VPC Service Controls can enforce conditional access on MCP attributes: mcp.toolName, mcp.method, and mcp.tool.isReadOnly, among others. Policy is no longer “this agent may reach Workspace.” It becomes “this agent may reach Workspace with read-only methods, and any email-send is denied at the boundary.”
Read that policy against the OWASP LLM Top-10 and the value gets concrete. Indirect prompt injection (ASI01) and tool misuse (ASI02 and ASI08) share a failure shape: the agent’s own credentials are used to do something the operator never intended, because a poisoned document or a crafted input told it to. IAM says the agent may call the tool. The firewall says the network path is open. Both are correct and both are useless against this class of attack, because the attacker is riding a legitimate identity through a legitimate path. MCP-attribute rules give you the missing enforcement point. VPC-SC blocks the destination even when IAM and the firewall would allow it. Grant the read, deny the write, at the perimeter, keyed on the specific MCP method rather than on the coarse identity.
This is the exfiltration answer the May convergence pointed at without naming. An injected agent that tries to POST your data to an external endpoint sails through valid credentials without friction. What stops it is a rule that says this identity’s egress is read-shaped only.
Session recording arrived for nonhuman identities
The third primitive comes from HashiCorp. Boundary 1.0 ships RDP session recording: capture and replay of every interactive action inside a session. Per the announcement, the release also sets a roadmap toward ephemeral authorization, on-behalf-of workflows, and continuous re-evaluation of access during a session, not just at its start.
The framing HashiCorp uses is the load-bearing part. Authenticate-once does not work for agents. Human access control assumes a person logs in, does bounded work, and logs out, and that re-checking them constantly would be friction with little payoff. An agent inverts every one of those assumptions. It can run for hours, change task mid-session, and take an action in minute fifty that has nothing to do with what it was authorized for in minute one. Continuous re-evaluation stops treating the login as the security decision and starts treating every action as one. Session recording is the audit companion to that: when an agent does something unexpected, you replay exactly what happened rather than reconstructing it from scattered logs.
Recording and continuous re-evaluation sit on the identity-and-session side of the bifurcation. VPC-SC MCP rules sit on the network side. A team that installs one and not the other has a real but partial control. You can know precisely what your agent did and still have let its data leave, or you can block the egress and have no replay of how the agent got there.
Do this now
Pick one production agent that touches sensitive data and run a two-column check this week.
Column one, the network layer. Does any perimeter rule key on what the agent does, not just who it is? If your egress policy is identity-only, an injected agent with valid credentials can exfiltrate and nothing stops it at the wall. Write one MCP-attribute rule for that agent: allow the read methods it genuinely needs, deny writes and sends at the perimeter. If you run on Google Cloud, that is now a VPC-SC ingress or egress rule with the agent as principal. If you run elsewhere, name the equivalent enforcement point and confirm it exists before you assume it does.
Column two, the identity and session layer. Can you revoke this agent at the perimeter, not only in IAM? Can you replay a full session after the fact? Is access re-evaluated during the session or only at authentication? If the answer to the last one is “only at login,” you are trusting a nonhuman identity the way you would trust a person, and the assumptions do not transfer.
You will likely find one column strong and the other empty. That is the normal state in July 2026, and it is fixable now that both sides ship as configuration rather than architecture diagrams. The vendors drew the perimeter. Enabling it is your move.
This analysis synthesizes Securing agentic AI: what’s new in VPC Service Controls (Google Cloud, July 2026), and Boundary 1.0 releases with RDP session recording and improved management (HashiCorp, July 2026).
Victorino Group helps engineering organizations build agent perimeters across the identity and network layers so a compromised agent is stopped at the wall, not just in IAM. Let’s talk.
All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →
If this resonates, let's talk
We help companies implement AI without losing control.
Schedule a Conversation