AI agent governance at Black Hat USA 2026 needs decision-level controls

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Zenity's event briefing: Black Hat USA 2026 event notice about securing AI agents at the decision level across SaaS, cloud and endpoint environments.

Why it matters: It matters because IAM and security teams need to govern what an agent decides to access or trigger, not just whether it can authenticate.

Context

AI agents are software that can select actions, tools and timing at runtime, which makes the governance problem different from ordinary automation. In this article, the issue is not simply that agents exist in enterprise systems, but that they are making decisions that can affect data access, downstream actions and other services.

Zenity uses Black Hat USA 2026 and the AI Summit on August 4 as the setting for an operational argument: security controls need to follow the agent's decision path. For practitioners, that shifts the focus from static access grants to runtime oversight, authorisation boundaries and evidence of what an agent was allowed to do.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents make authorization governance a higher priority than authentication?

A: Authentication proves who or what the principal is. Authorization decides what that principal may do in context. AI agents raise the priority of authorization because they can act at speed across many services after identity has already been accepted. If the allow or deny logic is weak, the identity layer has done its job and the breach still happens.

Q: What breaks when AI agent governance is treated as access control?

A: The control boundary breaks first. Governance tools can document what an agent is supposed to do, but they cannot stop the agent from authenticating, requesting privileges, or calling systems unless a separate runtime IAM layer enforces those decisions. That leaves a gap between policy intent and actual containment.

Q: What should teams do when an AI agent can act across SaaS, cloud and endpoint systems?

A: They should assign ownership for the full action path, not just for the agent account. The same identity can create different risks in different environments, so governance needs consistent policy, telemetry and escalation across each platform the agent touches.

Background and context

Decision-level authorisation for AI agents

AI agents differ from standard workflow automation because they can choose actions at runtime rather than only executing a fixed script. That means the real control point is not just login or API access, but whether a specific decision, tool call or downstream action is authorised in context. In practice, this creates a layered problem across SaaS, cloud and endpoints where the same agent may touch multiple systems within one task. Decision-level security therefore has to evaluate the intent, scope and effect of each agent action, not only the credential used to start the session.

Practical implication: define approval and policy checks around agent actions, not just around initial authentication.

Why enterprise agents create governance spillover

Enterprise agents such as Microsoft 365 Copilot, Google Gemini, Amazon Q and Salesforce Einstein sit close to business data and business processes, so a decision made by one agent can cascade into other systems. This is not just an access management issue. It becomes an authorisation and accountability issue because the agent can trigger actions, call connected services and interact with other agents without a human reading every intermediate step. When that happens, conventional IAM assumptions about stable operators and reviewable access histories start to fray.

Practical implication: map which business actions an agent can trigger across connected systems and set boundaries for each path.

Defense in depth for agent identity and behaviour

For AI agents, defense in depth has to cover identity, behaviour, telemetry and response. Identity alone does not explain what the agent may do after a successful login or token exchange. Behavioural control matters because the risk emerges when the agent combines data access, tool use and trigger execution in ways humans did not explicitly approve at runtime. In that sense, agent governance overlaps with observability and incident response, because teams need artefacts showing what the agent did, when it did it and which decisions crossed policy lines.

Practical implication: instrument agent activity so policy violations can be investigated at the action level, not only at the account level.

NHI Mgmt Group analysis

Decision-level control is now the correct unit of AI agent governance: identity alone is too shallow when the subject can choose actions, tools and timing at runtime. The decisive security question is no longer whether an agent is authenticated, but whether each agent decision is constrained to a defensible business purpose. Practitioners should treat the decision boundary as the control surface, because that is where abuse and error converge.

The governance assumption that access is stable enough to review is breaking down: access review models were designed for identities whose entitlements can be certified after the fact. That assumption weakens when an AI agent can chain multiple actions inside a single task and move faster than periodic governance cycles. The implication is that authorisation must move closer to issuance and execution, because post hoc review alone cannot describe the full behaviour.

AI agent security is collapsing the gap between IAM and runtime supervision: the article reflects a broader market shift from protecting credentials to governing decisions. Agents tied into SaaS, cloud and endpoint workflows create an identity problem that spans access, orchestration and evidence collection. That means IAM teams, PAM teams and security architects need a shared model for what an agent is allowed to decide, not just what it is allowed to authenticate to.

Identity blast radius is the right concept for agent governance: an agent's risk is not limited to the first system it reaches, because downstream triggers and connected services can extend the impact of a single decision. This is where traditional least-privilege thinking becomes too narrow if it only describes static permissions. Practitioners should think in terms of action radius, because that captures the practical spread of agent behaviour across the enterprise.

Black Hat-style visibility matters because agent governance is becoming operational, not theoretical: the market is moving toward controls that can explain and constrain runtime behaviour in real environments. That favours architectures that combine authorisation, telemetry and incident readiness instead of treating agent security as a policy-only problem. Security leaders should expect decision evidence to become a standard governance requirement for AI deployments.

What this signals

Decision-level governance will become the baseline for agent programmes: if a team cannot explain which agent decisions are allowed, the programme is not ready for production use. The practical shift is from static entitlement review to runtime authorisation evidence, because that is where the risky behaviour now lives.

The next stage of maturity is not more agent inventory alone. It is a control model that ties together authorisation, observability and response so every agent action can be traced back to an approved business purpose.

For practitioners

• Define decision boundaries for each agent Document which actions, tool calls and downstream triggers an AI agent may execute without additional review, and separate those from actions that require higher assurance or manual approval.
• Map agent-to-system blast radius Inventory every SaaS, cloud and endpoint service that an agent can reach, then trace how one approved decision can propagate into other systems or connected agents.
• Instrument runtime evidence for agent behaviour Capture the agent's decision, the triggered action, the target system and the policy result so investigators can reconstruct what happened after the fact.
• Separate authentication from authorisation Treat successful login or token use as only the starting point, then apply policy checks to each sensitive action the agent attempts inside the session.
• Review cross-platform governance coverage Check whether the same agent is governed differently across SaaS, cloud and endpoint environments, and close gaps where one platform sees the agent but another does not.

Key takeaways

• AI agents create governance risk at the decision layer because they can combine actions, tools and triggers across multiple systems.
• Authentication by itself is insufficient when the real exposure comes from what an agent does after it logs in.
• Security teams need runtime evidence and decision boundaries if they want to govern agent behaviour across SaaS, cloud and endpoints.

Key terms

• Decision-level control: Decision-level control is the practice of governing what an AI agent is allowed to decide, not only what account it uses. It focuses on the runtime choice to access data, invoke tools, or trigger downstream actions, which is where agent risk becomes operational.
• Agent Blast Radius: Agent blast radius is the amount of damage an AI agent can cause if it is compromised, misconfigured, or behaves unexpectedly. It includes the systems, data, identities, and actions the agent can reach through its permissions, tool access, and network paths, and is reduced by least privilege, segmentation, and strong controls.
• 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.
• Agent observability: Agent observability is the collection and correlation of traces, logs, metrics, and evaluations across an AI agent’s execution path. It explains what happened during model calls, tool use, handoffs, and downstream effects, but it does not itself authorize, deny, or revoke access.

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.