The Agent Gateway Is the Control Plane for Enterprise Agents

The move

Build a one-page answer sheet for the agents you run: six controls, six checks, and an evidence artifact for each result. Use it to evaluate a gateway pilot before expanding access to production tools. The deliverable is a tested boundary around a small workload, with an owner for every exception.

The news, once: the gateway market is taking shape

Palo Alto Networks announced its Portkey acquisition on April 30 and closed it on May 29, 2026, positioning Portkey as the AI Gateway for Prisma AIRS. Nutanix announced Agent Gateway availability in Enterprise AI 2.7 on May 26: the gateway was generally available, while the same announcement explicitly marked MCP server support as Tech Preview. Treat those as different availability claims when evaluating a deployment.

The Agentic AI Foundation also announced agentgateway joining its projects, giving buyers an open infrastructure option alongside vendor suites. These announcements establish product direction; they do not establish that every named product implements every control below.

TeamCopilot’s July 8 explainer frames the buying decision around access, approvals, secrets, logging, revocation, and team isolation. This runbook turns those questions into acceptance checks. For procurement tradeoffs, use the companion guide to open gateways and vendor suites.

Why acting agents changed the requirement

When software can deploy a service or issue a refund, a mistaken instruction can become a system change. Identity and permissions must survive that transition from text to action. Treat each agent as a privileged user, with a named owner and a deliberately limited role.

A gateway can enforce controls on traffic that passes through it. It cannot control an independent shell command, a local stdio server, or a provider key used over another network path unless those paths are separately constrained. Start by drawing that scope honestly; a proxy deployed in front of one endpoint is not fleet-wide enforcement.

The runbook: six controls to prove in a pilot

Pick one team, one agent identity, one read operation, and one reversible write against a test resource. Assign a reviewer who did not implement the policy. The configurations below are illustrative contracts, not a vendor API or ready-to-run gateway configuration. Time limits are suggested pilot targets to agree with your service owners.

These controls may span the gateway, identity provider, credential broker, and upstream service. Record who owns each enforcement point.

Step 1: inventory permitted access and bypass paths

Create a valid test identity with no tool grants. Check discovery and execution separately: can it see an unapproved tool, and can it invoke one by name? Hiding a tool from a list does not prevent a client from calling a known name.

# Illustrative inventory; review as policy data, not executable gateway config.
agent: spiffe://corp.example/agents/release-bot
owner: platform-oncall
default: deny
allow:
  - target: github-mcp/list_pull_requests
    resources: [example-org/test-service]
    operation: read
    review_by: 2026-12-01
  - target: models/review-default
    operation: inference
    budget_tokens_per_day: 2000000
exceptions: []

Then inspect provider credentials, container egress, CI jobs, local MCP processes, and alternate tool endpoints. For each route outside the gateway, either block it or record the separate control and exception expiry. Use filenames and secret identifiers in the inventory; never paste credential values into a ticket.

Pass: ungranted execution is rejected with a recorded policy reason; discovery follows the documented visibility policy; each approved operation has resource scope and an owner. Fail: a hidden tool still executes, or a governed workload retains an unrestricted alternate route. Extend the MCP hardening checklist with the bypass paths you found.

Step 2: bind approval to the actual action

Classify tools by implemented behavior and arguments. A get_* name or a server-supplied read-only hint does not prove that an operation is harmless. A search tool can return sensitive material, and a generic HTTP tool can perform almost any write.

Example action	Suggested pilot control	Approval binding
List test-repository pull requests	Resource-scoped read grant	Identity and repository
Create a test pull request	One human approval	Repository, branch, diff, arguments
Apply a production deployment	Service-owner approval; second reviewer where required	Artifact digest, environment, change record
Delete a protected resource	Deny except through an explicit change process	Exact resource and operation

Submit a harmless write for approval, then alter its arguments before execution. Repeat with an expired approval and with a second use of the same approval. Require the gate to reject all three. A useful approval record includes a digest of the canonical request, the approver, expiry, and whether it has been consumed.

Pass: the approved action executes once; changed, expired, or replayed requests cannot reuse it. Fail: approval means trusting an entire server indefinitely, or a broad chat response authorizes whatever the agent does next. Design the pending response around your protocol and workflow; pending_approval is an application state, not a universal MCP response.

Step 3: move upstream credentials out of model reach

Give the workload a scoped identity credential for the gateway. Where the upstream supports it, use a broker to obtain short-lived service credentials and inject them at the outbound hop. Some providers still require long-lived keys; isolate those in a protected broker and record that limitation. A gateway access token remains a credential even if it cannot call the provider directly.

Start with a filename-only screening pass against known existing directories:

# Linux/WSL example: reports filenames, never matching secret text.
rg --files-with-matches --hidden --glob '!node_modules/**' \
  -e 'sk-[A-Za-z0-9_-]{20,}' \
  -e 'ghp_[A-Za-z0-9]{36}' \
  -e 'AKIA[0-9A-Z]{16}' \
  ./agent-config ./transcripts
# Exit 1 means no pattern matched; exit 2 means the scan failed.

This catches only a few recognizable patterns. Run your approved secret scanner as well, inspect environment inheritance and filesystem permissions, and use a synthetic credential marker to test redaction. Zero regex hits are not proof that credentials are absent. The MCP authorization security guidance also rejects token passthrough: a server must not blindly forward a client’s token to a different upstream audience.

Pass: the model-facing environment cannot read upstream secrets; broker access is scoped and logged; synthetic markers do not enter prompts or retained transcripts. Fail: a personal access token is readable from a repository config, or the broker returns a usable secret as a tool result. A local vault helps organize secrets at the desk; access restrictions and broker enforcement remain separate responsibilities.

Step 4: reconstruct a run from exported evidence

Use a synthetic run that performs one allowed read, one denied write, and one approved write. Ask the reviewer to reconstruct it from exported records without opening the gateway’s console.

{
  "event": "authorization_decision",
  "run_id": "pilot-run-001",
  "request_id": "pilot-request-003",
  "agent": "spiffe://corp.example/agents/release-bot",
  "tenant": "payments",
  "tool": "deploy/apply",
  "resource": "test-service/staging",
  "decision": "allow",
  "policy_ref": "gates@v41",
  "approval_id": "pilot-approval-009"
}

That is an illustrative decision record. Emit a separate completion event with the same request ID, upstream operation ID, and outcome; authorizing a call does not prove it completed. Include denied requests and failed attempts. Redact before writing, limit access, and test retention with synthetic records.

Use storage whose write identity cannot delete prior evidence. If you use hash chaining, anchor checkpoints in a separately controlled store: a chain that an attacker can rewrite in full is not tamper evidence. S3 Object Lock’s documentation distinguishes governance mode from compliance mode; choose and verify the behavior you actually need.

Pass: the reviewer joins request, decision, approval, and completion unambiguously, including failures. Fail: logs say only that a key was used, a successful HTTP response is recorded as a successful deployment, or missing events cannot be detected. Fleet replay complements this record with session context.

Step 5: measure revocation and outstanding work separately

Agree a revocation target before testing; sixty seconds is a useful pilot target, not a protocol guarantee. Revoke the test identity through the real administration path while its workload attempts a harmless read every two seconds. Record the last successful admission, the first denial, and the policy version at each gateway replica.

Repeat for a team and for one tool across teams. An identity-provider change may not invalidate already-issued self-contained tokens immediately. Check gateway deny lists, token validation caches, issuer propagation, and refresh behavior. A one-hour token lifetime cannot by itself satisfy a sixty-second revocation target.

Next, start a deliberately slow test job and revoke its caller. Check whether the job stops, whether the upstream supports cancellation, and whether any side effect already happened. Revocation normally governs future admission; cancellation and rollback need separate mechanisms.

Pass: new requests are denied within the agreed interval across replicas, and outstanding work follows a documented cancel-or-reconcile procedure. Fail: revoking one workload requires rotating a shared key for unrelated teams, or operators assume a denied follow-up request undid an accepted deployment.

Step 6: test team isolation under pressure

Create two test tenants with different resources, quotas, and audit permissions. Team A exhausts its quota while team B continues making harmless calls. Revoke A, then try accessing A’s resources and audit partition as B.

Boundary	Evidence to collect
Identity and resources	Cross-tenant requests rejected at enforcement
Budget	A’s exhaustion does not spend B’s allocation
Policy management	A cannot modify B’s grants or approval rules
Logs	Each team sees only its authorized records
Shared capacity	A’s load does not exceed B’s agreed latency budget
Credentials	Upstream roles preserve required tenant separation

If the provider forces shared capacity or a shared account, make that an explicit architecture limit. Labels in a dashboard are not isolation; conversely, separate keys alone do not isolate a shared queue. Test both authorization and resource contention.

Pass: cross-tenant access fails and B stays within its documented service objective. Fail: tenant identity comes solely from a caller-controlled header, or global administrators can silently change policy without an audit trail. Keep emergency administrator access separate from ordinary team roles.

What breaks, and how you’ll know

The approval queue becomes the workaround factory. Watch queue age, approval expiries, and requests for direct access. Reduce unnecessarily broad gates, preserve controls on consequential writes, and make pending work visible to operators.

Policy drifts from the reviewed version. Compare deployed policy fingerprints with the approved revision and alert on unowned exceptions. Exercise the audit reconstruction after policy changes; a syntactically valid rule can still authorize the wrong resource.

The gateway becomes a single failure point. Measure gateway and upstream latency separately. Load-test the test tenant, drain a replica, and verify whether authentication, policy distribution, and audit delivery still work. Stateless MCP routing can simplify request distribution; it does not remove those dependencies.

Some calls never cross the boundary. Compare the catalog with endpoint discovery and egress observations. Investigate shadow MCP as a coverage gap, including local processes that a network gateway cannot see.

The operating-layer frame: the gateway and the desk

The organization needs identities, enforceable policy, and durable evidence around actions. The operator also needs to see which local session is waiting, which assistant produced the request, and where to resume work. Those views should share a run identifier where possible, while retaining their different responsibilities.

Automater’s desk-level role is local session and fleet visibility. It does not enforce the gateway controls in this runbook or replace the upstream audit trail. The multi-agent command center and company-PC operating model explain how that local layer fits. Explore Automater Lite and Pro for the local operating layer.

FAQ: agent gateways

What is an AI agent gateway?

An agent gateway mediates traffic between agents and models or tools. Depending on the implementation and connected services, it can authenticate callers, enforce permissions, meter usage, and record decisions. Human approval, credential brokering, and revocation behavior need explicit verification; the product category does not guarantee them.

Is an agent gateway different from an API gateway?

The categories overlap. An API gateway can supply authentication, routing, and quotas, while agent-focused products add MCP awareness, model accounting, and integrations for agent workflows. Evaluate the actual controls and failure behavior your workload needs rather than assuming a product name defines its architecture or security boundary.

Can one team start without buying a gateway?

Yes, if it can enforce the required controls through its existing identity, network, tool, and workflow systems. Start with the six checks and a limited workload. A gateway becomes useful when it centralizes repeated enforcement and evidence without creating unmanaged bypass paths or unacceptable operational overhead.

Sources

• Palo Alto Networks — Portkey acquisition announcement, April 30, 2026
• Palo Alto Networks — Portkey acquisition completion, May 29, 2026
• Nutanix — Agent Gateway availability and MCP Tech Preview, May 26, 2026
• Agentic AI Foundation — agentgateway joins AAIF
• TeamCopilot — agent gateway control questions, July 8, 2026
• MCP — authorization security best practices, revision 2026-07-28
• Amazon S3 — Object Lock retention and protection modes