Palo Alto Networks acquisition of Portkey reframes AI gateway governance

At a glance

What this is: Palo Alto Networks' acquisition of Portkey is positioned as a way to make the AI gateway a control plane for monitoring, orchestration, runtime protection, and agent identity security.

Why it matters: IAM teams now have to treat autonomous AI interactions as governed identities, because runtime decisions, tool use, and lateral movement risks no longer fit human-centric approval models.

👉 Read Palo Alto Networks' announcement on the Portkey acquisition and Idira

Context

An AI gateway is the runtime control point that sits between AI applications, models, tools, and data sources. In this acquisition, the governance problem is the trust gap that appears once agents can take actions independently, because traditional IAM assumes a request, an approval, and a stable subject behind the session.

For IAM and NHI teams, the practical question is whether identity controls can follow agent behaviour at execution time rather than only at provisioning time. That matters for access decisions, tool routing, telemetry, and cost control, because autonomous behaviour changes the boundary between authentication, authorisation, and governance.

Key questions

Q: How should security teams govern autonomous AI agents that can use tools at runtime?

A: Treat each agent as a governed identity with a defined tool scope, data reach, and interruption point. The key is not only authenticating the agent, but binding every runtime action to the policy state that authorised it. If the policy cannot follow the action path, the agent can drift into unauthorized access or unsafe tool use before any manual review occurs.

Q: Why do autonomous AI agents complicate least privilege models?

A: Least privilege is usually assigned before execution and reviewed after the fact, but autonomous agents can decide, act, and complete work within one session. That compresses the control window so tightly that a traditional entitlement review may never see the real privilege use. The result is a governance gap, not just a visibility problem.

Q: What breaks when AI gateway controls are treated like ordinary API security?

A: Ordinary API security assumes stable clients and predictable request paths. Autonomous agents can switch tools, chain calls, and change execution intent mid-session, so the gateway must enforce identity context and policy continuity across multiple steps. Without that, the organisation sees traffic but not the behavioural shift that creates risk.

Q: Who is accountable when an autonomous agent misuses access or exposes data?

A: Accountability should sit with the team that owns the agent lifecycle, policy, and runtime enforcement, not with the agent itself or with the model provider alone. If multiple groups share the control plane, they still need one named governance owner for recertification, monitoring, and incident escalation. Otherwise, the gap becomes a governance failure, not a technical one.

How it works in practice

Why the AI gateway becomes an identity control plane

An AI gateway is more than traffic routing when agents can call tools, choose models, and generate downstream actions. It becomes the place where requests are authenticated, policy is applied, telemetry is captured, and risky behaviour is interrupted before it reaches external systems. That makes the gateway structurally closer to an identity enforcement point than a simple API proxy. For identity teams, the important shift is that runtime governance now has to see the agent, the tool call, and the data path together, not as separate events.

Practical implication: treat the AI gateway as part of identity enforcement, not just application plumbing.

Agent identity security and the problem of tool misuse

Agent identity security focuses on proving which agent is acting and what it is allowed to touch in the moment it acts. That matters because autonomous systems can select tools dynamically, chain requests, and reuse context across multiple steps without a human operator watching each transition. The security problem is not simply authentication, but authorization continuity across the full action path. If the identity layer cannot preserve context through each call, the agent can drift from approved intent into unauthorized tool use or lateral movement.

Practical implication: bind every tool invocation to the agent identity and the policy state that authorised it.

Runtime protection for AI traffic and cost abuse

Runtime protection in AI systems has two jobs: stop malicious behaviour and catch unintended behaviour early enough to matter. In practice, that means watching for prompt-driven abuse, anomalous token consumption, unsafe data exposure, and requests that try to reach beyond the approved scope. The cost dimension is part of the identity problem because uncontrolled agents can create financial damage even when no classic breach occurs. Security leaders should therefore evaluate AI runtime controls for both security outcomes and governance outcomes, not just incident detection.

Practical implication: include token consumption, data exposure, and tool scope in the same control review.

NHI Mgmt Group analysis

AI gateway governance is becoming the identity boundary for autonomous systems. Once an agent can choose tools and execute without human approval, the control point moves from endpoint or app policy into the gateway itself. That shifts the governance burden from static access assignment to runtime mediation, and it places agent identity at the centre of enterprise control design. Practitioners should treat this as a category change, not a feature addition.

Least privilege was designed for access that persists long enough to be reviewed. That assumption fails when the actor is autonomous because the agent can acquire context, call tools, and complete a task within one execution window. The implication is that traditional entitlement review no longer describes the real decision surface, because the privileged action may already be complete before governance cycles can observe it.

Identity blast radius is now a first-order AI governance concept. The platform discussion here is really about limiting how far a single agent identity can move across tools, models, and datasets once execution begins. That is consistent with OWASP NHI and zero trust thinking, but it extends them into runtime AI operations where context, not just credentials, drives risk. Practitioners should reframe control design around blast radius, not only access lists.

Consolidation in AI security tooling shows that runtime governance and identity governance are converging. Vendors are no longer treating AI traffic inspection, agent identity, and observability as separate problems. That validates the direction of the market, but it also complicates programme ownership because IAM, security operations, and platform teams may all claim pieces of the same control plane. The likely outcome is tighter coupling between AI security and identity governance roadmaps.

Agent identity security will fail if it is implemented as a renamed secrets problem. Agents are not just workloads with credentials. They are decision-making subjects whose access, timing, and tool choice can change during execution. The implication for practitioners is that governance models must account for runtime behaviour, delegation chain depth, and policy continuity, or they will only secure the first hop.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader control baseline, see OWASP NHI Top 10 for the runtime risks that most often surface when agent identities are not governed as first-class subjects.

What this signals

Identity blast radius is the right planning concept for autonomous systems because the risk is no longer just credential exposure, but how far a single agent can move once it starts acting. Teams should pair gateway policy with lifecycle governance and review whether their current approval model still makes sense when execution is measured in seconds rather than sessions.

The broader signal is that AI security and IAM are converging into one runtime governance problem. Organisations that keep agent identity, observability, and tool policy in separate silos will struggle to explain what happened after an incident, especially when the control evidence lives in multiple platforms and no single owner can reconstruct the delegation chain.

For practitioners

• Map AI gateway functions to identity controls Identify which gateway functions enforce authentication, authorization, logging, policy, and interruption of unsafe requests. Make sure each control has a named owner in IAM or security engineering rather than leaving it inside application architecture.
• Classify autonomous agents as governed identities Create an inventory that records each agent, its tool set, its data reach, and its approval boundaries. Use that inventory for recertification, not just for discovery, so agents remain visible after initial deployment.
• Review policy for runtime scope drift Test whether an agent can move from an approved request to an unapproved action within the same session. Pay special attention to tool chaining, model switching, and access to downstream systems that were not part of the original task.
• Track cost as a governance signal Add token usage thresholds, anomaly alerts, and stop conditions to AI governance reviews. Unchecked spend is often the earliest sign that agent behaviour is no longer staying inside intended boundaries.

Key takeaways

• Autonomous AI changes the identity problem from entitlement assignment to runtime governance of action, tool use, and delegation.
• The reported scope creep in AI agent behaviour shows that governance gaps are already occurring in production, not just in pilots.
• Practitioners should align gateway controls, agent inventories, and recertification processes before autonomous systems become embedded in core business workflows.

Key terms

• AI Gateway: A control point that sits between AI applications and the models, tools, or data they call. In practice, it can authenticate requests, enforce policy, inspect runtime behaviour, and stop unsafe actions before they spread into connected systems.
• Agent Identity Security: The discipline of proving which AI agent is acting and what it is allowed to do at the moment it acts. It extends beyond authentication to include runtime authorisation, delegation boundaries, and policy continuity across tool calls.
• Identity Blast Radius: The amount of access, data reach, and downstream movement a single identity can create once execution starts. For autonomous agents, the concept matters because one approved action can quickly expand into broader tool use, data exposure, or lateral movement.

Deepen your knowledge

AI gateway governance, agent identity security, and runtime access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for autonomous agents from a similar starting point, it is worth exploring.

This post draws on content published by Palo Alto Networks: Palo Alto Networks completes acquisition of Portkey to secure AI agents. Read the original.