Palo Alto Networks acquires Portkey for AI agent governance

At a glance

What this is: This is an acquisition-led consolidation move for AI agent governance, with Portkey's AI Gateway being integrated into Prisma AIRS to centralise control of autonomous agent activity.

Why it matters: It matters because IAM, PAM, and NHI teams now have to decide where runtime authorisation for AI agents sits, what gets logged, and how governance survives dynamic tool use.

Context

AI agent governance is the set of controls that decide what an agent may access, which tools it can call, and how those permissions are enforced while the system is running. Static IAM models assume access can be granted, reviewed, and revoked around stable roles. That assumption weakens when the actor chooses actions at runtime.

This acquisition signals that control of agent identity and authorisation is moving toward unified platforms rather than isolated point capabilities. For NHI programmes, that raises a governance question, not just a tooling question: which team owns policy, evidence, and lifecycle control when an autonomous system can initiate access decisions on its own?

Key questions

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

A: Security teams should govern runtime agent choice as an access event, not as a simple application action. That means scoping permissions to the task, limiting token lifetime, logging every tool decision, and blocking the agent from reaching systems outside its approved context. Static roles alone are not enough when the execution path changes on each run.

Q: Why do autonomous AI agents change the authorization model?

A: Autonomous agents can alter their tool use, scope and sequencing after access has been granted, so the original authorization decision may no longer match the action being taken. That means static RBAC or OAuth scopes are necessary but insufficient. Teams need runtime evaluation that checks the action in context, not just the token at issuance.

Q: What breaks when AI agents are governed like ordinary service principals?

A: The main failure is that ordinary service-principal governance assumes a stable workload with predictable lifecycle and entitlement patterns. AI agents can inherit access from a blueprint, act through user-shaped interfaces, and change their operational state at runtime, so the control model no longer matches the behaviour. Teams need a separate governance view for the agent runtime, not just for the underlying credential object.

Q: What should teams evaluate before adopting a unified AI gateway?

A: Teams should evaluate where identity authority, policy enforcement, and audit logging actually sit, and whether those functions are preserved outside the application layer. A gateway only helps if it becomes the enforceable choke point for delegated access. Without that, the organisation gains another integration layer but not stronger governance.

How it works in practice

Runtime authorisation for AI agents

AI agents do not behave like ordinary service accounts because they can select actions and tools during execution. That means authorisation is no longer just a provisioning-time decision. The control problem shifts to whether the gateway can evaluate intent, context, and tool scope at the moment of use, rather than relying on predeclared permissions alone. In practice, this is closer to decision-time access brokering than traditional role assignment, and it becomes harder as agents chain prompts, tools, and external services in one session.

Practical implication: authorisation for agents has to be evaluated at runtime, not assumed safe because a role was approved earlier.

AI gateway as the policy and telemetry choke point

An AI gateway sits between the agent and the tools or data sources it calls, making it a natural place to inspect prompts, route requests, enforce policy, and record evidence. That architecture matters because autonomous workflows need a central control point where identity, tool access, and audit trails converge. Without that choke point, governance is fragmented across app code, model wrappers, and downstream APIs, which makes enforcement inconsistent and incident reconstruction difficult.

Practical implication: place logging, policy enforcement, and access mediation at the gateway layer, not only inside individual applications.

Why agent governance is an identity problem

The core issue here is not model quality but identity authority. If an AI agent can call tools, retrieve data, or trigger actions, then the organisation is effectively assigning a non-human identity a set of permissions and delegated responsibilities. That creates the same lifecycle questions seen in NHI governance, but with more volatility because the agent's task scope can change mid-session. The important distinction is that the subject is not simply an automated workflow, but an actor making independent runtime decisions within bounded authority.

Practical implication: treat agent governance as delegated identity governance, with explicit scope, evidence, and revocation rules.

NHI Mgmt Group analysis

AI agent governance is becoming delegated identity governance, not a model-management problem. Once an agent can choose tools and execute tasks, the security question becomes who granted that authority, how it is constrained, and how it is revoked. That shifts the centre of gravity from prompt safety to control over runtime privileges. Practitioners should treat agent governance as an identity lifecycle issue with audit and revocation requirements.

Runtime decisioning is the named concept that breaks static authorisation assumptions. AI agents can select actions at the moment of execution, which means least privilege can no longer be defined only at provisioning time. The practical implication is that policy must follow the session, not just the identity record, because the effective permission set changes as the task unfolds. That is a structural change in how authorisation is governed.

Unified gateways will matter because fragmented enforcement cannot keep pace with agentic access paths. When policy, logging, and routing are split across app code and downstream APIs, no team has a complete view of what the agent actually did. A gateway architecture can improve coherence, but only if ownership, evidence, and escalation paths are clearly defined. Teams should re-evaluate whether their current controls can prove what an agent was allowed to do versus what it actually did.

The market is signalling a move from isolated AI controls to platform-level governance layers. That consolidation will simplify some operational decisions, but it can also obscure where identity authority truly lives. Security leaders should expect sharper scrutiny of control boundaries between model access, tool access, and business workflows. The implication is that governance programs will need clearer accountability for non-human actors across the full lifecycle.

From our research library:

• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Runtime scope drift: AI agents can acquire, combine, and discard tool permissions within a single task, which means governance evidence must come from execution logs rather than from static approval records. That changes how teams think about authorisation, because the control point moves closer to the moment of action than the moment of onboarding.

The consolidation of gateway, policy, and audit functions suggests that agent governance will increasingly be judged by how well a platform can prove delegated authority end to end. 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey. Teams should prepare for governance models that treat autonomous access as operational reality, not future planning.

For practitioners

• Define agent authority boundaries Map each AI agent to the minimum tools, data sources, and actions it can use, then separate read, write, and execution permissions so scope changes are visible and reviewable.
• Centralise runtime enforcement at the gateway Use an AI gateway or equivalent control point to mediate requests, record decisions, and keep policy enforcement separate from application logic.
• Instrument agent activity for auditability Capture prompt, tool-call, and downstream action evidence in a form that supports reconstruction of delegated access and incident review.
• Review lifecycle ownership for non-human actors Assign clear ownership for onboarding, scope changes, and offboarding of AI agents so delegated access does not outlive the business task.

Key takeaways

• AI agent governance is maturing into a delegated identity problem, where tool use, runtime context, and revocation matter more than static role assignment.
• The central risk is not just access breadth but runtime scope drift, which makes conventional review and approval models less reliable for autonomous systems.
• Security teams should build control points around gateway enforcement, evidence capture, and lifecycle ownership so agent authority stays bounded and auditable.

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.
• Autonomous AI Agent: An autonomous AI agent is software that can perceive inputs, decide what to do, and act with limited or no human prompting. In identity security, it is treated as a non-human identity when it can authenticate, call tools, access data, or trigger workflows under its own runtime decisions.
• 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.
• Delegated Identity: Delegated identity is when one actor acts on behalf of another with explicit permission and bounded authority. In AI-assisted commerce, it requires clear consent, limited scope, and traceable records so the retailer can distinguish authorised delegation from unauthorised automation.

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.