Palo Alto Networks acquires Portkey for AI agent governance

At a glance

What this is: Palo Alto Networks is integrating Portkey’s AI Gateway into Prisma AIRS to centralise control for autonomous AI agent governance.

Why it matters: For IAM and security teams, the shift underscores that AI agent access, tool use, and policy enforcement now need to be governed alongside NHI and human identity controls.

👉 Read Protect AI's analysis of Palo Alto Networks acquiring Portkey for AI agent governance

Context

AI agent governance is becoming an identity problem, not just a security feature checklist. Once an agent can select tools, call services, and act without human approval at every step, the key question becomes which identity rules apply to that runtime behaviour and where those rules are enforced.

Palo Alto Networks’ move to integrate Portkey into Prisma AIRS reflects a broader market pattern: buyers want a unified control plane for autonomous systems, but the governance challenge still sits with entitlement scope, policy enforcement, and auditability. That makes this relevant to NHI, agentic AI, and adjacent IAM programmes at the same time.

Key questions

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

A: Security teams should treat the agent as a governed identity, not just a workload. Bind every tool, API, and data source to explicit policy, then require audit logs that show which identity made each call and why. If the agent can switch tools freely, the control boundary must exist at runtime, not only at provisioning.

Q: Why do autonomous AI agents create a different IAM problem from ordinary automation?

A: Ordinary automation follows predefined workflows, so access can be reviewed against a fixed script. Autonomous agents choose actions, tools, and timing at runtime, which means privilege scope can change during execution. That makes static approvals and one-time access reviews insufficient for proving governance or limiting blast radius.

Q: What do organisations get wrong about gateway-based AI agent controls?

A: They often assume a gateway solves governance by itself. In reality, a gateway can enforce policy at one choke point, but it cannot replace lifecycle ownership, entitlement scoping, or downstream auditability. Without those controls, the agent may still accumulate broad effective access across systems.

Q: Who should be accountable when an AI agent makes an unauthorised decision?

A: Accountability should sit with the business owner of the workflow and the technical owner of the identity controls, not with the agent itself. The organisation needs a clear model for who approves scope, who reviews logs, and who can suspend access when the agent’s behaviour drifts beyond intent.

How it works in practice

AI gateway control planes and agent runtime policy

An AI gateway sits between agent requests and downstream tools or APIs, where it can apply routing, policy checks, logging, and guardrails. In an enterprise setting, that makes it a control point for tool invocation, model mediation, and access decisions. The architectural question is not whether the gateway exists, but whether it can enforce policy consistently across heterogeneous agents, tool stacks, and sessions without becoming a false sense of control. For identity teams, the hard part is binding agent behaviour to governance evidence that survives audit and incident review.

Practical implication: treat the gateway as one enforcement layer, not the identity authority for the whole agent stack.

Autonomous AI agents and delegated access boundaries

Autonomous agents differ from ordinary automation because they can decide what action to take, which tool to use, and when to execute it. That creates a delegated-access problem that sits between IAM, PAM, and workload identity, especially when the agent can move across systems during one task. If policy only governs the front door, the agent can still widen its effective reach through tool chaining, API calls, or indirect data access. That is why agent governance has to account for runtime behaviour, not just provisioning-time approval.

Practical implication: map every tool and data source an agent can reach, then constrain each path separately.

Policy enforcement for agentic identity and secrets

Agentic systems frequently rely on secrets, tokens, and temporary credentials to reach tools and data. The risk is not just leakage, but over-broad reuse of credentials across sessions and tasks. In practice, teams need to understand whether the agent is using a stable identity, ephemeral access, or a brokered credential flow, because each model changes blast radius and audit expectations. That is especially relevant where the same agent can trigger actions across infrastructure, SaaS, and internal APIs under one policy envelope.

Practical implication: separate credential issuance from policy evaluation so access scope can be narrowed without breaking traceability.

NHI Mgmt Group analysis

Platform consolidation is turning AI agent governance into an identity architecture decision. When gateway controls are folded into broader security platforms, practitioners should assume the market is moving toward unified policy planes rather than standalone agent tools. That shifts evaluation from feature comparison to control placement, audit durability, and whether policy decisions are enforceable across identity domains. The practical conclusion is that agent governance now belongs in the core identity architecture conversation.

Autonomous agent access breaks the assumption that access is only meaningful at provisioning time. Least privilege was designed for conditions where the actor’s access pattern is known, stable, and reviewable over time. That assumption fails when an autonomous agent can choose tools and execute within runtime context, because the effective privilege boundary can expand and contract inside the same session. The implication is that identity programmes must rethink how they define and evidence privilege, not just add another policy layer.

AI gateway controls do not replace NHI governance, they expose its missing boundaries. A gateway can mediate calls, but it cannot by itself resolve who owns the agent, what identity the agent is acting under, or how entitlement drift is recorded across downstream systems. That makes lifecycle ownership, credential scope, and auditability the real control questions. Practitioners should read this as a sign that agentic AI is forcing NHI governance to mature, not fragment.

Identity blast radius is becoming the decisive risk metric for agentic systems. The governance issue is no longer whether an agent can be observed, but how far its access can travel once it starts chaining tools and services. That is a cross-domain problem spanning IAM, PAM, secrets, and workload identity. The practical conclusion is that teams should judge agent control planes by how much blast radius they can actually contain.

Platform vendors are signalling that agent governance will be consumed inside broader security stacks. That may simplify procurement, but it also raises the bar for integration quality across IAM, logging, and policy evidence. If identity controls cannot survive that consolidation, they will be treated as implementation detail instead of governance foundation. The practitioner takeaway is to verify whether the control plane preserves identity boundaries, not just whether it centralises management.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to The 2026 Infrastructure Identity Survey.
• For a broader control perspective, see OWASP NHI Top 10 for the risk patterns that emerge when agents can chain tools and actions.

What this signals

With 70% of organisations already granting AI systems more access than they would give a human performing the same job, the governance gap is not theoretical. Agent controls now need to be evaluated as identity controls, with policy, logging, and entitlement scope treated as one operating model.

Identity blast radius: the real question is how far an agent can move once it starts chaining tools, not whether it passed an initial policy check. That is why teams should test whether access boundaries still hold after the first API call and the second delegated action.

As agentic AI moves into platform security stacks, security teams should benchmark their controls against the OWASP Agentic AI Top 10 and check whether enforcement remains visible to IAM, PAM, and audit functions, not just the gateway layer.

For practitioners

• Define the agent identity boundary Document which runtime identities are used by autonomous agents, which systems they can reach, and which approvals are required before those identities can act across tools.
• Separate policy enforcement from credential issuance Ensure that access decisions, token brokerage, and logging are not collapsed into one opaque layer, so you can narrow scope without losing traceability.
• Review downstream entitlements by tool path Map the exact APIs, SaaS apps, and internal services each agent can invoke, then remove any standing access that is not required for a single task path.
• Require auditable ownership for each autonomous workflow Assign a named business and technical owner to every agentic workflow so lifecycle decisions, incident triage, and access reviews have an accountable human reference.

Key takeaways

• AI agent governance is now an identity architecture problem because runtime decisions can expand effective privilege beyond provisioning-time assumptions.
• Platform consolidation around AI gateways may simplify control points, but it does not remove the need for explicit ownership, entitlement scoping, and audit evidence.
• Practitioners should measure agent risk by identity blast radius, not by whether a gateway exists in front of the tools.

Key terms

• Agentic identity: An agentic identity is the runtime identity used by an AI system that can make decisions, select tools, and act without a human approving every step. It needs governance for scope, ownership, and auditability because its behaviour can change during execution.
• Identity blast radius: Identity blast radius is the amount of systems, data, and actions that become reachable if an identity is mis-scoped, abused, or over-privileged. For autonomous systems, it is measured by how far the actor can move across tools and services before review or containment occurs.
• AI gateway: An AI gateway is a control layer that sits between an agent and downstream tools or services. It can enforce routing, policy checks, logging, and guardrails, but it does not by itself replace lifecycle ownership, entitlement design, or identity governance.
• Delegated access: Delegated access is permission granted to one identity to act on behalf of another or to access shared systems within a defined scope. In agentic environments, it must be tightly bounded because the runtime actor may choose actions that expand effective privilege beyond the original intent.

Deepen your knowledge

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

This post draws on content published by Protect AI: Securing and Governing AI Agents At Scale Through a Unified AI Gateway. Read the original.