Open-Source Agent Gateway vs Vendor Security Suite: Pick the Layer You Refuse to Lock In

The move

Create a one-page decision record for which gateway functions stay portable and which you buy together. Use it to set exit requirements, test retained audit records, and ask vendors consistent questions.

The news, once: agentgateway joins the AAIF, Portkey folds into Prisma AIRS

The Agentic AI Foundation announced on June 4, 2026 that agentgateway became an AAIF-hosted project. The foundation describes an Apache 2.0, Rust-based gateway for model, MCP, A2A, and conventional API traffic, with authentication, external authorization, CEL policy, and observability. Foundation hosting does not certify your deployment.

Palo Alto Networks announced its Portkey acquisition on April 30 and closed it on May 29. Its releases position Portkey as the AI Gateway within Prisma AIRS, alongside the suite’s broader security and identity functions.

A third example shows why release labels need reading carefully. Nutanix’s May 26 Agent Gateway announcement says the gateway is generally available in Enterprise AI 2.7, while MCP server support is explicitly Tech Preview. Test the particular control and protocol path you need; an overall GA label is not a feature-by-feature guarantee.

These are different packaging and governance choices. The runbook below is an editorial decision method for your deployment, not a benchmark ranking of those products.

Why acting agents changed the requirement

An acting agent needs decisions at the tool boundary: who may call, with which authority, against which resource. The gateway control plane can centralize those checks for traffic you route through it. Tool servers and providers still need their own authorization and audit; an agent with a direct credential can bypass an otherwise well-designed gateway.

That changes the lock-in question. For a chatbot, switching vendors meant re-pointing an endpoint. For an agent that is a privileged user, switching can mean changing identity trust mappings, retesting approval gates, and moving retained audit history. Score the resulting migration work per layer.

The runbook: open-source vs vendor agent gateway, one layer at a time

Start with the decision record, then test its assumptions.

Step 1: decompose “the gateway” into six layers

Evaluate six functions separately, even when they arrive in one product. Some deployments buy only a subset; others assemble adapters around an open gateway.

Layer	What it does	What you would have to move
Routing and model abstraction	One endpoint in front of providers and self-hosted models; MCP and A2A proxying; failover; budgets	Every agent’s endpoint, SDK, and client config
Policy and approvals	Which agent may call which tool; which actions need a human; deny-by-default rules	The rule set and every re-certification behind it
Identity and secrets	Who the agent is, whose behalf it acts on, which scoped credential it receives	Every issued identity and brokered secret
Audit and logging	The record of every call, decision, approval, and policy version	Years of history in whatever format it was written
Detection and response	Injection and anomaly detection on live traffic; kill switch; quarantine	Tuning, playbooks, alert routing
Catalog and inventory	Which MCP servers, models, and tools are sanctioned; discovery of the rest	The sanctioned list and the discovery method

Two notes. Newer MCP headers can simplify request classification, but client/server versions and optional extensions still affect compatibility; what gateways do with the 2026-07-28 spec is its own piece. And approvals are a policy layer, not an install step, because approve-once is dead.

Step 2: score lock-in cost against integration value

Score every layer on two axes, 1 to 5 each. This table is a worked example for a team with an existing IdP and a small platform staff, not measured vendor scores. Lock-in cost measures adapter rewrites, re-approvals, and retained-history migration. Integration value measures consolidated operations, correlated detection, and support.

Layer	Lock-in cost	Integration value	Read
Routing and model abstraction	4: every agent is wired to it	2: routing is commodity	Keep portable
Policy and approvals	5: rewrite plus re-certify each gate	3: useful, not decisive	Source stays yours; any engine may enforce
Identity and secrets	4: re-issue everything	5: what suites are for	Buy, if your IdP is the issuer
Audit and logging	5: years of retention	3: nice, not required	Keep portable
Detection and response	2: swapping is a re-tune	5: tuned by specialists	Buy
Catalog and inventory	3: the list is data	4: discovery is hard to build	Buy discovery; own the list

Attach adapter counts, retention requirements, staff time, contract terms, and a migration exercise to each score. Re-score when they change.

Step 3: write the refusal rule

Use these thresholds as an explicit decision policy for this example.

• Lock-in cost 4 or higher and integration value 3 or lower: refuse single-vendor lock-in. Open format, open protocol, your storage, your repo.
• Integration value 4 or higher and lock-in cost 3 or lower: buy the pane. Account for the staff required to operate it.
• Both 4 or higher: buy, with the exit written into the order form and tested before signature. Identity lands here; the fix is that your IdP issues the identities and the suite brokers them, then test whether a swap preserves subjects, audiences, role mappings, and revocation. An unchanged issuer reduces migration work; it does not remove it.
• Both 3 or lower: whatever is cheapest this year.

Record the choice and the evidence supporting it.

# control-plane-decision.yaml — illustrative shape; one page, dated, owned
decided: 2026-09-04
owner: platform-security
refuse_lock_in: # portable, ours, in formats we can read without a login
  - routing_boundary # OpenAI-compatible + MCP/A2A at the edge; config in git
  - audit_record # OTel/JSONL to storage we own; the vendor gets a copy
  - policy_source # gates as code in our repo; engines evaluate, never own
consolidate: # one pane, bought
  - detection_response
  - discovery_catalog # discovery is theirs; the sanctioned list is our file
  - identity_broker # condition: identities issued by our IdP
exit_test_last_passed: null # step 5, quarterly
review: renewal minus 180 days

Assign an owner and review before renewal or a provider change.

Step 4: draw the dependencies before choosing a mixed architecture

One possible architecture places an open gateway at the boundary, evaluates policy under your control, and exports durable audit events to storage you administer. A security service consumes selected telemetry for detection and investigation. Findings lead to reviewed policy changes, while emergency response uses a separate, authenticated path to suspend access. This is a design option, not a claim that most teams or every vendor support it.

The diagram separates the request path from asynchronous analysis. Identity issuance and credential brokering remain explicit dependencies outside this simplified view.

Telemetry-only detection sees an event after it occurs. If you need a vendor verdict before a tool executes, use a synchronous authorization or inspection integration and budget its latency and failure behavior. Credential brokering also belongs in the authenticated call path; it cannot be supplied by a service that only reads yesterday’s logs.

An inline suite can be a valid choice. Check its actual export, external authorization, and protocol support. Agentgateway’s documentation shows that even a compatibility layer supports some provider APIs natively, translates others, and leaves some unavailable. Run your tool-call, streaming, retry, and model-switch tests against the exact route rather than assuming one endpoint erases provider differences.

Policy portability needs more than a familiar language. CEL evaluates expressions over data provided by the embedding application; each engine chooses its attributes, functions, and enforcement behavior. Keep a vendor-neutral decision specification plus a tested adapter for each engine.

# gates.yaml — illustrative policy contract, NOT an installable gateway config
- name: deploy-needs-two-humans-after-hours
  match: tool.name == "deploy.apply"
  when: >
    principal.kind == "agent" &&
    delegation.role == "contractor" &&
    (context.local_hour < 9 || context.local_hour >= 18)
  require:
    approvals: 2
    distinct_approvers: true
    approver_group: platform-oncall
    bind_to: [tool, target, arguments_hash, policy_version]
    expires_after_minutes: 10
    record: [policy_ref, approver, decision]

The adapter derives identity and local time from trusted context, including a named timezone. It rejects missing attributes, binds approvals to the exact operation, and invalidates them when arguments change. CEL alone does not collect approvals or prevent replay. Add conformance cases for business hours, after hours, expired approval, duplicate approver, missing identity, and changed arguments. Portability means the same decisions survive translation, not that arbitrary YAML runs unchanged everywhere.

Step 5: the exit test, or replay last quarter without the vendor

Run this before signature and every quarter after. Pick one agent and one week from last quarter. Using only the raw records in your own storage and open tools, answer four questions: what did it call, what was it denied, who approved the exceptions, and which policy version was in force at each decision. Also identify the verified principal and delegated authority.

-- illustrative: DuckDB over the audit export you own, no vendor console involved
SELECT date_trunc('day', CAST(ts AS TIMESTAMP)) AS day,
       tool, decision, policy_ref, approver, count(*) AS n
FROM read_json_auto('audit/2026-Q2/*.jsonl')
WHERE agent_id = 'spiffe://corp.example/agents/platform/release-bot'
  AND CAST(ts AS TIMESTAMP) >= TIMESTAMP '2026-06-08'
  AND CAST(ts AS TIMESTAMP) < TIMESTAMP '2026-06-15'
GROUP BY ALL ORDER BY day, tool;

Define the export schema first: include nullable approver fields on non-approval events, explicit timestamps, decisions, and policy versions. Restrict access and redact payload secrets; an owned bucket still needs authentication, encryption, and retention controls. Compare exported counts with source event counts so a sampling or delivery gap cannot masquerade as a complete audit.

If any answer requires logging into the vendor, that layer is locked in, whatever the contract says. If the export lacks policy_ref or approver, the audit record is decorative. The same principle applies to local fleet replay: retain independently readable records.

Step 6: questions to ask each vendor, verbatim

Ask every vendor the same eight, in this order, and write the answers into the decision record.

1. “Show me the audit record for one tool call as a file on my disk. What format is it, and which fields exist only in your console?”
2. “If we terminate, what do we export, in what format, over what window, and at what price?”
3. “Which policy language does your engine evaluate, and can I run the same policy file outside your product?”
4. “Express this gate for me: a deploy call by an agent acting for a contractor, after hours, needs two approvers from on-call. Show me the rule, not the screen.”
5. “Who issues the identity an agent presents at your boundary, and can I revoke it from my IdP in under a minute?”
6. “Can I put an open gateway in front of you and feed you its telemetry instead of routing through you? Name what I lose.”
7. “What changes in my agents’ configuration if you change your endpoint or SDK next year?”
8. “What is the audit retention price after year one, and per what unit?”

Use question 6 to identify architectural dependencies. A product may need inline access for pre-execution blocking or credential exchange. Record which guarantees disappear in telemetry-only mode and decide whether those tradeoffs fit your threat model.

What breaks, and how you’ll know

Renewal exposes migration cost. Watch new export or retention fees, obsolete decision records, and migrations nobody can estimate. Schedule the exit test before negotiations, with an owner who can explain each failed query and missing field.

Exports omit the decision. A CSV with timestamps and tokens may omit policy versions, approvers, or denied calls. Check event completeness against source counts. A screenshot cannot replace a queryable record, and sampled traces alone are insufficient for an audit requiring every action.

Gates exist only in a wiki. Demonstrate the actual two-approver workflow, missing-identity refusal, and approval expiry. Count agents retaining direct provider credentials and investigate shadow MCP connections. Use the agent security checklist to probe bypasses alongside the approved route.

The operating-layer frame: the org control plane and the operator’s desk

Whichever mix you choose, the organization’s gateway policy applies to calls that actually cross its boundary. Provider permissions, endpoint restrictions, and exported audit evidence complete the picture. Keep the organization-level decision record current and exercise the exit test while the existing product is still available.

The operator also needs local context: which session produced a change, whether it stalled, and what transcript remains. Automater’s supported session Library and local workflow views can help with that desk-level work; they do not issue identities or enforce gateway policy. Link retained session IDs to organization audit events where your tooling records both. That connection makes corporate AI operations and daily agentic ops easier to investigate. Explore Automater Lite for the local session side.

FAQ: open-source vs vendor agent gateways

Is an open-source agent gateway enough on its own?

It depends on the controls your workload needs and the team operating it. An open gateway can provide routing, authorization, and observability, but you must configure, monitor, and test them. Evaluate detection quality, incident response, identity integrations, and audit export separately; foundation governance does not substitute for deployment evidence.

What is the difference between an AI gateway and an agent security suite?

A gateway is the control layer between an agent and the tools or models it uses: routing, policy, identity checks, logging. A suite bundles a gateway with detection, response, identity, and a console spanning your estate. Prisma AIRS with Portkey inside is a suite; agentgateway is a gateway.

How do I avoid lock-in with a vendor agent security suite?

Decide the layers before the contract. Keep the protocol boundary, the audit record, and the policy source in formats you own; buy detection and discovery as one pane. Write the exit terms, bulk export, format, and retention into the order form, then run the replay test before renewal minus 180 days.

Sources

• AAIF — agentgateway joins the foundation (June 4, 2026)
• Palo Alto Networks — Portkey acquisition announcement (April 30, 2026)
• Palo Alto Networks — acquisition completion (May 29, 2026)
• Nutanix — Agent Gateway GA and MCP Tech Preview scope (May 26, 2026)
• Agentgateway — standalone capabilities and provider compatibility
• CEL — expression language and application embedding