Palo Alto Networks Portkey acquisition raises the bar for AI agent governance

At a glance

What this is: Palo Alto Networks is tying Portkey to Prisma AIRS to treat the AI gateway as a central control plane for autonomous agent traffic, governance, and runtime enforcement.

Why it matters: IAM and security teams need to rework identity, privilege, and audit models because autonomous agents behave more like privileged insiders than traditional applications.

👉 Read Palo Alto Networks' intent to acquire Portkey and secure AI agents

Context

AI agent governance is the problem space here, not the acquisition itself. The article argues that as enterprises move from copilots to autonomous agents, existing security models break because the agent becomes a runtime decision-maker that can touch internal and external systems directly.

That matters for identity programmes because an AI agent is not just another workload and not yet a human user either. The control question becomes how to govern agent identity, privileged access, tool routing, and auditability when the system can act at machine speed across many services.

Key questions

Q: How should security teams govern autonomous AI agents that use tools and APIs?

A: Treat autonomous agents as governed identities, not as generic automation. Put authorization, routing, and logging at the transaction layer so every tool call is checked in context. Then assign an owner, scope, and review process to each agent-to-tool path. That gives identity teams a way to enforce policy where the action happens, not just where the agent was created.

Q: Why do autonomous AI agents change least privilege requirements?

A: Autonomous agents change least privilege because their access cannot be assumed to stay fixed for the full life of a session. They can choose tools, change intent, and execute without human approval between actions. Security teams need controls that bind privilege to the task and transaction, not to a broad standing role that outlives the immediate use case.

Q: What breaks when AI agents are given broad standing access?

A: Broad standing access breaks governance because the agent can move from one task to another without a fresh authorization check. That creates a control gap between intended scope and actual runtime behaviour. The result is weak accountability, limited containment, and audit trails that show activity without explaining why the activity was allowed.

Q: Who is accountable when an autonomous agent takes an unsafe action?

A: Accountability should sit with the owner of the agent, the approver of the policy, and the team operating the downstream system. If those responsibilities are not explicit, incident review becomes a blame exercise instead of a control review. The safest model is to predefine ownership before deployment, then validate it through access and audit processes.

How it works in practice

AI gateway control plane for agent identity and traffic

An AI gateway sits between agent requests and the tools, models, or data sources they can reach. In this model, it can inspect traffic, enforce policy, route requests, and record audit logs in one place. The architectural point is that governance moves closer to the transaction itself, rather than relying on static IAM records after the fact. For autonomous agents, that control plane becomes the boundary where identity, authorization, and data protection meet. Without that layer, each downstream tool has to make its own trust decision, which is harder to govern consistently.

Practical implication: map every agent-to-tool path to a central enforcement point before agents reach production.

Least privilege for autonomous agents is a runtime problem

The article frames AI agents as highly privileged insiders because they can execute many automated decisions across systems. That changes least privilege from a provisioning-time concept into a runtime control problem. Traditional permissions models assume the subject and purpose of access remain stable long enough to define scope in advance. Autonomous agents can switch tasks, call tools, and expand activity within a single session. As a result, the security question is not only who owns the account, but what the agent is allowed to do at the moment of action.

Practical implication: bind agent permissions to task scope and transaction context, not to broad standing access.

Telemetry and audit logs become the evidence layer for agent governance

The source emphasises deep telemetry and audit logs because agentic behaviour must be reconstructible after the fact. In practice, that means identity teams need logs that show which agent acted, which model or policy route it used, which tool it called, and what data it touched. For autonomous systems, this is not just observability. It is the evidence base for compliance, incident analysis, and privilege review. If the path from intent to tool use is not visible, governance can exist on paper while the real control plane remains opaque.

Practical implication: require per-transaction audit evidence that ties each agent action to identity, policy, and target system.

NHI Mgmt Group analysis

Autonomous agents expose an identity governance problem, not just a tooling gap. The article is really about what happens when a software actor can select actions at runtime across internal and external systems. That behaviour pushes agent identity beyond the boundaries of normal workload governance and into a control plane where authorization must follow the transaction, not the deployment. Practitioner implication: identity programmes need to treat agent behaviour as a first-class governance domain.

Least privilege was designed for access that can be bounded in advance. That assumption fails when the actor is autonomous because task selection, tool choice, and execution timing are decided during the session. The implication is not simply tighter policy, but a rethink of what it means to define privilege for an actor whose intent is not fixed at provisioning time.

AI gateway control points are becoming the practical seam between identity and application security. As agent populations grow, the category is moving toward centralized enforcement for routing, telemetry, and policy checks. That does not remove the need for IAM, PAM, or NHI governance. It means those controls now have to be expressed through a runtime mediation layer that can keep up with agent-to-agent and agent-to-tool exchange. Practitioner implication: align identity governance with the transaction path, not the model catalogue.

Autonomous agent governance will force convergence between NHI controls and AI security operations. The same questions that shaped NHI programmes, such as privilege scope, auditability, and offboarding, now apply to agentic systems with stronger runtime variability. That widens the programme from credential management into behavioural governance. Practitioner implication: the next control gap is likely to be between identity teams and AI platform teams, not inside either function alone.

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 44% of organisations have implemented any policies to govern AI agents, even though 92% agree governance is critical to enterprise security.
• For a broader control baseline, review OWASP Agentic AI Top 10 for the runtime risks that should shape policy design.

What this signals

Autonomous agent governance will increasingly look like high-risk NHI governance with a runtime layer on top. The practical shift is from periodic review of static access to continuous mediation of behaviour that can change inside a session. With 80% of organisations already seeing AI agents act beyond intended scope, the control gap is no longer theoretical.

Identity teams should expect pressure to align AI platform governance with established NHI controls around ownership, scope, auditability, and offboarding. The difference is that autonomous actors compress those questions into live execution, which makes the transaction path the new unit of control.

Security programmes that already track workload identity, privileged access, and tool routing have the right building blocks. The next step is to tie those controls to agent behaviour and to use resources such as the OWASP Agentic AI Top 10 as the policy reference point.

For practitioners

• Inventory all agent-to-tool connections Build a complete map of which autonomous agents can reach which models, APIs, MCP servers, and internal systems, then assign an owner to each path. If you cannot explain the business purpose of a connection, it is not ready for production.
• Move authorization checks into the runtime path Require policy enforcement at the AI gateway or equivalent mediation layer so that decisions are checked at the point of use, not only at provisioning. This is especially important where agents can call multiple tools in one session.
• Tie audit logs to agent identity and tool use Make every log line answer four questions: which agent acted, what policy allowed it, which tool it used, and what data or system it touched. That evidence is what supports incident review and access certification later.
• Rework privilege reviews for changing session context Review whether your access governance assumes a stable actor with a stable purpose. Autonomous agents can drift across tasks within one runtime session, so the review unit should be the transaction path, not the account alone.

Key takeaways

• Autonomous AI agents turn identity governance into a live runtime problem because they can choose tools and actions without a human approval gate.
• The article's central signal is that centralized AI gateways are becoming the control layer where identity, policy, routing, and audit need to meet.
• Practitioners should move from broad standing access to transaction-scoped enforcement, or agentic behaviour will outrun the review model.

Key terms

• AI Gateway: A control point that brokers traffic between an AI agent and the tools, models, or data it can reach. It is used to inspect requests, enforce policy, route actions, and preserve audit evidence so governance can happen at the moment of execution.
• Agentic Identity: The identity assigned to an AI system that can choose actions and tools at runtime rather than following a fixed script. It needs ownership, scope, and audit controls because its behaviour can change during a session and affect systems beyond the original prompt.
• Runtime Authorization: Authorization applied at the moment a request is made, not only when access is provisioned. For autonomous agents, this matters because the agent can change tasks or tool use inside a session, so static entitlements may not reflect actual risk.

Deepen your knowledge

Autonomous agent identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending NHI controls into AI agent environments, this course is a strong place to start.

This post draws on content published by Palo Alto Networks: Palo Alto Networks to Acquire Portkey to Secure the Rise of AI Agents. Read the original.