AI Agent Frontdoor series — Post 4 of 6
At A Glance
- A new exception per agent does not scale, and each one widens the attack surface.
- Approve one access pattern, then reuse it for every vendor’s agents under one policy model.
- Authorization runs per identity, per service, and per MCP tool, with every request logged to the SIEM.
- One door is not one weak point: it has no route into the network, the systems stay dark, and a per-vendor kill switch cuts access in seconds.
In this series
The prior post showed how outbound-dialing connectors take the network team out of the critical path for every agent. Someone still has to approve that pattern, and that someone is you. This post is for the security architect and the CISO who have to sign off on a vendor cloud reaching into the enterprise, and who carry the risk when it goes wrong.
One exception per agent doesn’t scale
Today each agent arrives as its own request: a new public endpoint, a new firewall exception, and a review with no agent-level identity to anchor it. You approve it, and the next one lands, slightly differently, with its own justification. The exceptions pile up, each one a small widening of the attack surface, and none of them share a model you can reason about as a whole. The work grows with the business’s appetite for agents, and so does the risk you own.
Approve the pattern, not the endpoint
NetFoundry Frontdoor replaces the exception-per-agent habit with a single approved pattern. You approve one way for a vendor’s agent to reach an internal system: outbound connectors, identity-bound sessions, and policy enforced at the connector. Every new agent then fits that pattern instead of asking for a new hole through the firewall. You reason about one design, harden it once, and apply it everywhere, which is a far stronger position than defending a drawer full of one-off exceptions.
Identity down to the tool
Authorization is enforced at a granular level within this pattern. Policy is defined by identity and attributes and enforced per service and per MCP tool, so an agent reaches the specific tools it needs and nothing else. Every request is recorded to your SIEM, which gives you the identity-level audit trail that an allow-list or a shared tunnel cannot produce. You see which agent reached which service, through which tool, and when.
“Isn’t one door one big target?”
The strongest objection to a single control point is concentration risk, and it deserves a direct answer. Frontdoor is a policy enforcement point, not a route into your network. It holds no standing path to your systems, the connectors dial outbound, and the systems behind it stay dark to the internet, so there is no exposed target to pivot from. Every session is bound to an identity, every request is logged, and a per-vendor kill switch lets you cut one vendor’s access in seconds without touching the others. One door you can see, govern, and close beats many doors you cannot.
What the auditor sees
When an auditor asks who can reach the core banking API and under what policy, you answer from one place: the identities authorized, the tools each may call, and the full record of what they did. The per-vendor kill switch gives you a demonstrable control for third-party risk, which is exactly the area regulators are pressing as third-party involvement in breaches climbs. The next post turns to the platform and integration teams who stand up the systems these agents call.
Read the rest of the series
Prior: A Hostname Instead of a Hole, the network team’s view.
Next: The Credential the Vendor Already Uses, the platform and integration view.
Frequently Asked Questions
How is per-tool authorization different from app-level access?
App-level access decides whether an identity can reach a system at all. Per-tool authorization decides which specific MCP tools or services the agent may call once it is there, so you grant the minimum an agent needs.
Doesn’t routing every agent through one door create a single point of failure?
The door enforces policy and holds no route into your network, and the systems behind it stay dark. Sessions are identity-bound, requests are logged, and a per-vendor kill switch isolates any one vendor without affecting the rest.
What does the SIEM actually receive?
A record of each authorized request: the identity, the service and tool reached, and the time, so you have an identity-level audit trail rather than connection logs from a shared tunnel.
How fast can we cut off a vendor?
The per-vendor kill switch revokes that vendor’s access in seconds, and only that vendor’s, because each runs under its own identity and policy.
