Agentic AI security now hinges on continuous threat modelling

At a glance

What this is: ActiveFence’s Black Hat 2025 analysis says agentic AI is exposing old control weaknesses in new places, especially as AI systems move from generating content to taking actions.

Why it matters: IAM, PAM, NHI, and AI security teams need to treat delegated machine actions as governance objects because the risk now sits in access scope, session control, and third-party trust.

Context

Agentic AI changes the security problem because the system is no longer only producing text or predictions, it is taking actions that can create real operational outcomes. That shifts the governance focus from content moderation and model quality to access control, identity assurance, and the trust boundaries around tools, APIs, and third parties.

The article frames Black Hat 2025 as the point where this shift became visible in practitioner conversations. The core gap is that many organisations still apply sequential review models to a runtime problem, while agentic systems can request, use, and hand off privileges inside workflows that move faster than traditional governance cycles.

Key questions

Q: What breaks when agentic AI is governed only as a data platform problem?

A: The control model breaks because data governance does not answer who or what is acting on the data at runtime. Once agents can invoke tools, write records, or trigger workflows, teams need identity, privilege, and traceability controls that follow the action, not just the dataset.

Q: Why do agentic AI workflows increase risk when RBAC and API permissions are broad?

A: Because the agent can turn broad standing access into immediate impact. If a workflow can call tools, reach APIs, or inherit a user session without narrow scope limits, a single prompt or compromise can expand into data access, configuration change, or downstream abuse. Least privilege only works when the agent’s runtime scope is genuinely constrained.

Q: What are the warning signs that GenAI governance is failing in production?

A: Common signs include rising token spend without clear business growth, poor traceability of prompt flows, inconsistent routing between models, and backend services that still contain long-lived API keys. If teams cannot explain who is calling what and why, governance is not working.

Q: How should organisations respond when a supplier’s AI use creates fourth-party risk?

A: They should extend due diligence beyond the direct vendor and ask how downstream AI services affect authentication, data handling, logging, and incident response. The practical test is whether the enterprise can still trace and revoke access if a hidden dependency changes behaviour. If not, supplier assurance is incomplete.

Technical breakdown

Agentic AI turns access scope into the primary control surface

Agentic AI systems do not just consume data. They invoke tools, call APIs, and make state-changing decisions on behalf of a user or workflow. That means the security boundary moves from model output filtering to authorisation design, where permissions, session context, and delegation rules determine what an agent can actually do. In practice, the most important question is not whether the model can generate a harmful answer, but whether it can trigger a harmful action through an allowed integration path. This is why RBAC gaps, weak session design, and broad API entitlements become more dangerous once an AI system can act. Practical implication: treat agent permissions as runtime controls, not static setup decisions.

Practical implication: treat agent permissions as runtime controls, not static setup decisions.

Why third-party trust becomes fourth-party exposure

The article’s fourth-party risk point is really about trust propagation. When a vendor uses AI, and that vendor’s vendor also uses AI, the effective attack surface extends beyond the direct supplier relationship. Each delegated connection can add its own APIs, secrets, identity assumptions, and review blind spots. This is especially relevant where an AI workflow depends on external services that are themselves changing quickly or operating with limited transparency. The security challenge is no longer just whether the direct supplier is trusted, but whether hidden dependencies can alter data handling, privilege use, or incident response readiness. Practical implication: map upstream dependencies that can change agent behaviour without your direct oversight.

Practical implication: map upstream dependencies that can change agent behaviour without your direct oversight.

Continuous threat modelling is becoming a runtime governance requirement

Traditional threat modelling assumes a system can be reviewed before it is deployed and then monitored later. Agentic AI breaks that assumption because behaviour can change as prompts, tools, policies, and external context change. That makes the threat model a living control rather than a one-time document. Frameworks such as the NIST AI Risk Management Framework, MAESTRO, and emerging OWASP agentic guidance matter here because they help teams reason about evolving attack paths, not just static architecture diagrams. The deeper issue is governance latency: if the control only activates after review cycles, it is already behind the system. Practical implication: move threat modelling into the build, test, and runtime loops for AI systems.

Practical implication: move threat modelling into the build, test, and runtime loops for AI systems.

NHI Mgmt Group analysis

Continuous threat modelling is now the organising principle for agentic AI governance. The article’s strongest point is not that AI creates new risks, but that agentic systems compress the time between decision, tool use, and impact. That makes annual or even quarterly review cycles structurally too slow for the problem. The field should treat runtime modelling as a governance discipline, not an optional testing enhancement. Practitioners should assume that the relevant control boundary is moving as quickly as the agent itself.

Agentic AI exposes the weakness of treating access review as a post-hoc control. Once an agent can acquire and use privileges inside a single workflow, reviewing entitlements after the fact does not close the gap that mattered. This is a genuine identity governance issue, not just an AI safety issue, because the security question is who or what may act, through which tool, under which session, and with what delegation boundary. Practitioners should shift control intent from certification to issuance-time restriction and traceability.

Fourth-party AI risk is the next governance blind spot. Enterprises are increasingly assessing direct suppliers, but the article shows how AI usage propagates trust through nested vendors and hidden integrations. That creates a supply-chain governance problem with identity consequences, because every additional AI-enabled dependency can change secrets handling, API exposure, and incident visibility. Practitioners should assume supplier review is incomplete unless it includes downstream AI use and delegated access paths.

Human oversight remains necessary, but it is no longer sufficient as a primary control. The article correctly highlights the operational limits of humans in the loop when systems act at machine speed and scale. Human review should be reserved for high-risk escalation points where it can still influence the decision path. Practitioners should build controls that prevent unsafe delegation before human fatigue turns oversight into theatre.

Agentic AI security is becoming a control-plane problem, not a content problem. The named concept here is the action-control gap: organisations can explain model outputs, but they struggle to govern the actions taken by connected tools, agents, and vendors. That gap will define the next phase of AI security maturity. Practitioners should align AI governance with IAM, PAM, API access, and continuous monitoring rather than isolated model review.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Action-control gap: agentic AI now creates a mismatch between who is allowed to decide and what the system can actually do. The safest control point is the moment of tool invocation, not the post-execution review. For practitioners, this means AI governance must sit alongside IAM, PAM, and session control rather than living only in model review workflows.

The supply-chain angle is just as important. ActiveFence’s Black Hat analysis points to third- and fourth-party AI use as a multiplier for trust exposure, and 92% of organisations expose NHIs to third parties, according to the Ultimate Guide to NHIs. That makes delegated access paths, supplier AI usage, and revocation readiness central programme questions, not niche architecture issues.

For practitioners

• Implement runtime authorisation for agent actions Constrain every high-risk tool call to explicit, context-aware approval conditions so the agent cannot exceed its intended task scope.
• Inventory third- and fourth-party AI dependencies Map where suppliers, sub-processors, and embedded AI services can alter data flows, permissions, or response paths without direct notice.
• Move threat modelling into delivery pipelines Re-run AI threat models whenever prompts, tools, policies, or integrations change, not only at design sign-off.
• Place humans at escalation points only Reserve manual review for delegation, privilege expansion, and irreversible actions so routine decisions do not become review bottlenecks.
• Tie AI governance to IAM and API controls Use identity-bound policy, scoped tokens, and auditable session design to limit what an agent can reach through connected services.

Key takeaways

• Agentic AI shifts the core security problem from what models say to what connected systems can do on their behalf.
• Broad permissions, nested suppliers, and delayed review cycles create the conditions for agent-driven impact that traditional AI governance misses.
• The practical control response is to govern actions at issuance and invocation time, then keep threat models and oversight continuously updated.

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.
• 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 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.
• Continuous Threat Modeling: Continuous threat modeling is the practice of updating threat analysis as code, dependencies, and architecture change rather than treating it as a one-time exercise. In fast-moving development environments, it helps teams anticipate supply chain weaknesses earlier, align controls with current exposure, and make risk decisions closer to the point of change.

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 helps practitioners connect access control and lifecycle governance to the security decisions their programmes now face.