Agentic AI security now hinges on continuous threat modelling

At a glance

What this is: This is an analysis of how Black Hat 2025 conversations reflected a shift from generative AI risk to agentic AI risk, with the key finding that foundational security failures are resurfacing in new forms.

Why it matters: It matters to IAM and security practitioners because agentic AI expands the identity surface, amplifies privilege and session risk, and forces governance teams to rethink how delegated access is monitored and contained.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read ActiveFence's analysis of Black Hat 2025 AI security and agentic risk

Context

Agentic AI changes the risk profile because software no longer just predicts or generates, it can act, sequence tasks, and use tools on its own. That moves the problem from model output quality to governance of access, identity, and delegated authority. In practice, existing RBAC, session controls, and third-party review processes were built for slower human or service workflows, not for machine systems that can chain decisions quickly.

Black Hat 2025 discussions reflected a broader shift in security thinking: the most visible AI risk is no longer only prompt abuse, but the way AI workflows inherit old identity weaknesses and expose them at higher speed. For IAM, PAM, and NHI teams, that means the control plane around AI agents matters as much as the model itself. This is now a typical enterprise pattern, not an edge case.

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 create new risk in non-human identity management?

A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts. They can connect quickly, persist across teams, and accumulate permissions that are hard to review. That combination increases the chance of unnoticed access drift and credential exposure.

Q: What do teams get wrong about RBAC for AI systems?

A: They assume a role definition is enough to control behaviour. In agentic environments, the same role can be used in different contexts, with different tool calls and different downstream effects. Effective governance requires policy tied to runtime context, not just static role labels, plus telemetry that shows what the agent actually did.

Q: How should organisations respond when third-party AI tools expand the trust chain?

A: They should extend vendor review beyond the primary supplier to connectors, embedded models, and downstream services that inherit credentials or data access. The goal is to see the full machine-to-machine trust chain, then decide where access can be reduced, segmented, or isolated before production use.

Technical breakdown

Why agentic AI turns identity into an execution layer

An AI agent is not just a model. It is a software entity that can decide when to call tools, what actions to take, and how to sequence those actions toward a goal. That means the agent’s identity, credentials, and permissions become part of the execution path. If the agent can reach APIs, data stores, or automation tooling, then identity is no longer only about authentication. It becomes the mechanism that determines what the agent can actually do, how long it can do it, and whether those rights are bounded to a task or persist across sessions.

Practical implication: treat agent identity as a runtime control point, not a registration detail.

Why RBAC and session management break down under AI workflows

RBAC assumes roles map cleanly to repeatable job functions, but AI-driven workflows often cross functional boundaries in a single task. Session management is also strained because machine activity can be short-lived, bursty, and difficult to inspect after the fact. When an agent uses tokens, APIs, or delegated permissions to perform multi-step work, the real issue is not only whether access was approved. It is whether the access path was narrow enough, observable enough, and revocable fast enough to stop unintended downstream action.

Practical implication: scope agent sessions to task boundaries and monitor every delegated action path.

Why supply chain and fourth-party risk now extend into AI toolchains

The article’s fourth-party point matters because AI workflows rarely stop at the first vendor. A primary supplier may embed AI, then its dependencies, model services, connectors, and plugins add more hidden trust relationships. That is a supply-chain problem with identity consequences. Every additional integration can introduce another credential, another trust boundary, and another place where governance assumptions fail. The more the workflow depends on external systems, the more likely it is that access review misses the actual runtime path.

Practical implication: map third- and fourth-party AI dependencies to the credentials and permissions they inherit.

Threat narrative

Attacker objective: The attacker’s objective is to convert trusted AI workflow access into broader system abuse, data exposure, or credential theft.

1. Entry begins when an attacker reaches AI-enabled workflows through exposed APIs, weak session handling, or compromised third-party trust relationships.
2. Escalation follows when the attacker abuses delegated permissions, service credentials, or tool access to expand from the initial workflow into broader systems and data paths.
3. Impact occurs when AI-driven actions are used to access sensitive data, reveal credentials, or trigger unauthorised downstream operations at speed.

NHI Mgmt Group analysis

Agentic AI is becoming a governance problem before it becomes a model problem. The core issue is that organisations are deploying systems that can take actions, not just generate outputs, while still governing them with controls designed for static software. That mismatch creates a control gap across IAM, PAM, and third-party oversight. The practitioner conclusion is straightforward: if the agent can act, it must be governed like a privileged runtime principal.

The new named concept here is the delegated action gap: the distance between an AI system’s approved task and the real privileges it can exercise while completing that task. This gap grows when access is mediated through APIs, connectors, and vendor ecosystems that were never designed for continuous scrutiny. The more complex the workflow, the easier it is for review processes to miss what the agent can actually reach. Practitioners should assume task approval is not the same as privilege containment.

RBAC alone does not describe AI agent risk well enough. Role assignment is too coarse when an agent’s actions vary by prompt, context, or runtime decision path. That is why AI governance now needs identity-aware policy, explicit tool scoping, and continuous telemetry, not just role mapping. In NHIMG terms, this is where agentic AI security intersects directly with NHI governance: the agent is a non-human actor whose access must be lifecycle-managed, not merely enabled.

Supply-chain review must now include machine-to-machine trust chains. The article’s fourth-party warning shows that AI risk is spreading through dependencies, not just primary applications. Each added connector or embedded model can expand the credential footprint and create a new blind spot for security teams. The practical conclusion is that procurement, IAM, and product security teams need a shared inventory of AI-linked trust relationships.

Continuous security is no longer a slogan, it is the operating model. When AI systems can perform work asynchronously and at scale, annual reviews and end-of-project checks are too slow to matter. Threat modelling, red teaming, and runtime policy enforcement have to sit inside the delivery lifecycle. Practitioners should treat AI security as an always-on control plane rather than a post-deployment checkpoint.

What this signals

Delegated access, not model output, is becoming the control plane problem. As organisations move from chatbots to agents that can act, the security team’s job shifts toward runtime containment, tool scoping, and auditability. That means IAM and PAM owners should expect AI agents to be folded into access governance workflows, not handled as a separate innovation track.

Agentic AI security will increasingly depend on NHI lifecycle controls. If a software entity can obtain, use, and discard privileges, then its identity needs lifecycle management just like any other non-human principal. Teams should align agent governance with Ultimate Guide to NHIs , 2025 Outlook and Predictions and the OWASP Agentic AI Top 10 to anchor control design in recognised risk patterns.

Continuous red teaming is moving from optional assurance to operational necessity. The article’s Black Hat observations point to a world where AI workflows must be tested like production attack surfaces, not just reviewed like projects. Security programmes should expect policy drift, connector sprawl, and hidden trust chains to be the recurring failure modes.

For practitioners

• Define agent-level identity boundaries Assign each AI agent a discrete identity, then bind it to task-scoped credentials, approved tools, and explicit session expiry so access cannot outlive the work it was meant to do.
• Separate human approval from runtime authority Require policy checks at execution time, not only at onboarding or deployment, so an approved workflow cannot silently expand into new systems, datasets, or connector paths.
• Inventory fourth-party AI dependencies Map every external model, connector, and embedded AI service to the credentials and permissions it inherits, including hidden downstream trust chains that procurement reviews often miss.
• Embed continuous agent red teaming Test AI workflows against prompt injection, tool misuse, credential exposure, and lateral movement scenarios on an ongoing basis, then feed the findings into access policy changes.

Key takeaways

• Agentic AI changes security by turning access into action, which makes identity controls central to runtime safety.
• Foundational weaknesses such as RBAC gaps, weak session control, and third-party trust expansion become more dangerous when AI systems can execute workflows.
• Security teams should move to continuous, identity-aware governance for AI agents rather than relying on end-stage review processes.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Delegated Action Gap: The mismatch between an AI system’s approved purpose and the real privileges it can exercise while completing a task. The gap widens when permissions are inherited through connectors, APIs, and service accounts that are not continuously governed.
• Fourth-party risk: Fourth-party risk is the exposure created by a vendor’s own vendors, sub-processors, and downstream service dependencies. It matters because direct contractual control usually stops at the first tier, while operational and data-risk propagation often continues much further through the chain.
• Runtime Policy Enforcement: Runtime policy enforcement evaluates a request at the moment it is executed instead of relying only on preconfigured permissions. For AI agents, this allows decisions to reflect current context, target sensitivity, and behavioural signals rather than static assumptions.

What's in the full article

ActiveFence's full blog covers the operational detail this post intentionally leaves for the source:

• Black Hat session references and practitioner anecdotes that show how AI risk is being discussed in the field
• Specific examples of the RBAC, API security, and session management issues observed across AI implementations
• The article's proof-of-concept and safety guidance for teams testing AI systems against attacker-style scenarios
• Vendor-specific context on how ActiveFence positions its own AI risk-scoring approach

👉 The full ActiveFence post covers the Black Hat themes, practitioner observations, and the safety guidance in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and agentic AI identity. It is designed for practitioners who need to connect identity controls to real operational risk across modern security programmes.