Palo Alto Networks acquisition of Portkey reframes AI gateway governance

At a glance

What this is: This is Palo Alto Networks' acquisition of Portkey, framed around using an AI Gateway to govern autonomous agents, inspect AI traffic at runtime, and reduce trust gaps, unauthorized actions, and cost blowouts.

Why it matters: It matters because IAM and security teams now have to govern AI agents as acting identities, not just tools, which shifts control from model access to runtime authorisation, observability, and privilege boundaries.

Context

AI gateway governance is the control problem that appears when autonomous agents can take actions, call tools, and route requests without a human approving each step. In that model, the risk is no longer limited to model output quality. The challenge becomes whether the organisation can observe, authorise, and constrain agent behaviour at runtime across every interaction.

Palo Alto Networks says Portkey’s gateway architecture will sit inside Prisma AIRS to monitor, orchestrate, and govern agent traffic at scale. For identity and access teams, that shifts the discussion from prompt safety to the governance of agent execution, especially where agents are treated as privileged users and can move between tools, models, and workflows.

The article is typical of the current market direction: AI security is converging with identity, observability, and runtime control rather than remaining a model-layer concern. That makes AI Gateway governance relevant not only to AI platform teams, but also to IAM, PAM, and NHI owners who now have to account for machine actors with decision-making authority.

Key questions

Q: What breaks when autonomous coding agents are given broad access?

A: Control breaks down when the agent can move across tools and repositories without tight limits on scope, attribution, or revocation. Broad access turns the agent into an uncontrolled identity layer, making it harder to know what was changed, who approved it, and whether the permissions still match the task.

Q: Why do autonomous agents create a trust gap for identity teams?

A: Because the agent can select actions, call tools, and trigger work without waiting for a human at each step. That makes static entitlement reviews incomplete, since the real risk is how the agent behaves in context. Identity teams should focus on execution-time policy, not just who received access at onboarding.

Q: What are the signs that an agent governance programme is failing?

A: Common signals include unknown agents in staging or production, unvetted MCP connections, broad or long-lived credentials, and logs that show service-account activity without clear ownership. If the security team cannot map the agent to a tool chain and accountable owner, governance is already behind the deployment.

Q: How should teams compare AI gateways and traditional IAM controls?

A: Traditional IAM controls answer who is allowed to authenticate and what role they hold. AI gateways answer what the agent may do right now, with this tool, in this session, against this request. For autonomous systems, both matter, but the gateway carries the runtime decision that IAM alone cannot express.

How it works in practice

Why AI gateways become the control plane for agent identity

An AI gateway sits between the agent and the rest of the environment, so it can inspect requests, route traffic, and enforce policy before downstream systems are touched. In this context, the gateway is not just a network intermediary. It becomes the runtime trust boundary for autonomous agents, where authorisation, telemetry, and policy enforcement converge. That matters because an agent can move across models, tools, and APIs in ways that a static access model does not anticipate. When the control plane sees every interaction, it can associate actions with an agent identity and impose policy at the point of execution rather than after the fact.

Practical implication: Practitioners should treat the gateway as a policy enforcement point for agent identity and not as a logging layer alone.

What runtime inspection changes for AI traffic

Runtime inspection means the system evaluates AI requests while they are in motion, not only during build-time testing or offline review. For autonomous agents, that is the difference between reviewing a transcript and stopping a harmful action before it reaches a model, API, or data store. It also helps surface novel agent-based threats because the control observes actual traffic patterns, tool calls, and output behaviour in production. This is especially relevant when the same agent can generate text, call tools, retrieve data, and trigger workflow steps. The security problem is therefore behavioural and transactional, not only content-based.

Practical implication: Security teams should align runtime inspection with the exact tool paths and data flows an agent can trigger.

Why agent identity security matters when agents are treated as privileged users

Agent identity security is the idea that each agentic interaction should be authenticated and attributable, so the system can distinguish one agent from another and govern what each one may do. That resembles privileged access management more than traditional chatbot oversight. The article’s language about preventing unauthorized tool use and lateral movement shows the real issue: once an agent can act independently, identity becomes the control surface for limiting scope. Without strong identity binding, multiple agents can blend into generic AI traffic, making attribution and revocation weak. The platform story is therefore about governing machine actors as accountable identities, not as anonymous services.

Practical implication: IAM and PAM teams should define unique agent identities, scoped tool permissions, and revocation paths before production rollout.

NHI Mgmt Group analysis

AI gateway governance is becoming the new runtime boundary for autonomous agents. The article reflects a broader shift away from viewing AI security as a prompt or model problem. Once agents can choose actions and invoke tools, the decisive control is the place where requests are inspected, authorised, and constrained in real time. Practitioners should read AI gateways as enforcement points, not as passive traffic relays.

Least privilege for agents cannot be managed only at provisioning time. Autonomous agents can move through models, tools, and workflows dynamically, which means static entitlements do not fully describe the risk. That does not just create a control gap, it breaks the assumption that intent is knowable before execution. The implication is that identity governance for agents has to account for runtime context, not just issued permissions.

Agent identity security is the machine analogue of privileged access governance. The article’s emphasis on authenticating every agentic interaction shows that attribution and scope control now matter as much as model access. Without unique identities and revocation paths, agent traffic collapses into an undifferentiated stream that cannot be governed cleanly. Practitioners should treat each agent as an accountable actor with its own trust boundary.

AI observability and identity governance are converging into one control problem. The acquisition links telemetry, orchestration, and access control because each alone is incomplete when the actor is autonomous. Observability without identity leaves actions unowned, and identity without runtime telemetry leaves misuse invisible. The practical implication is that agent governance will increasingly require cross-functional ownership across IAM, PAM, SecOps, and AI platform teams.

Runtime token and cost controls are now part of security governance, not only FinOps. The article’s token monitoring language signals that uncontrolled agent behaviour has both security and economic consequences. When an agent can loop, retry, or chain tool calls, cost spikes can be an operational symptom of governance failure. Practitioners should treat excessive consumption as a control signal tied to agent trust and scope.

From our research library:

• 54% of organisations are actively deploying AI agents across workflows, yet only 21% report a mature governance model for agentic AI.
• Read next: Agentic AI Identity Guide

What this signals

Agentic AI governance will increasingly be decided at execution time. Identity programmes built around onboarding, recertification, and standing privilege will miss the moment when an autonomous agent chooses and executes the wrong action. That makes gateway enforcement and runtime authorisation the controls that matter most for production AI.

Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey. That gap means many teams are adopting agentic workflows before they have a governable identity model for them.

AI Gateway governance will become a shared concern across IAM, PAM, SecOps, and AI platform teams. The control surface spans identity, telemetry, and policy enforcement, so ownership cannot sit with a single function. Practitioners should plan for joint accountability around agent identities, runtime rules, and incident response.

For practitioners

• Define unique agent identities Assign each autonomous agent its own identity, trust boundary, and revocation path so access can be traced back to a specific actor rather than a shared AI channel.
• Enforce runtime authorisation at the gateway Apply policy checks before an agent can call tools, models, or data sources, and tie those checks to task scope rather than blanket platform access.
• Map privileged tool access to agent purpose Document which tools each agent may use, why those tools are needed, and which actions require tighter constraints or separate approval paths.
• Instrument agent activity for behavioural outliers Monitor repeated retries, unusual tool sequences, unexpected data access, and abrupt token spikes as signs that the agent has drifted outside its intended role.
• Separate observability from enforcement Use telemetry to explain what the agent did, but keep the gateway policy layer responsible for deciding whether the action is permitted.

Key takeaways

• AI gateway governance is becoming the control layer that decides whether autonomous agents can act safely at runtime.
• The identity problem is no longer limited to login and access grant, because agents can select tools and execute tasks independently.
• Practitioners need identity binding, runtime policy, and observability together if they want to govern agent behaviour in production.

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: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Trust gap: The space between what a customer expects from a transaction and what the merchant proves after checkout. In digital commerce, it often grows when confirmation, shipping updates, refunds or legitimacy signals are unclear, delayed or inconsistent.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.