AI security risk assessments are rising, but continuous control still lags

At a glance

What this is: AppSOC’s article argues that AI risk assessments are increasing, but static review cycles still leave fast-changing AI systems and agents exposed to new vulnerabilities.

Why it matters: This matters because IAM, PAM, and NHI teams are increasingly responsible for governing AI tools and agents whose access, behaviour, and integrations change faster than traditional review processes can keep up.

By the numbers:

• 87% of organisations report that AI-related vulnerabilities increased over the past year.
• AI security risk assessments have nearly doubled, rising from roughly 37% to 64% of organisations in a single year.

👉 Read AppSOC's analysis of why AI security risk assessments still lag behind real-world AI change

Context

AI security risk is not behaving like a traditional annual review problem. Models change, integrations expand, and AI agents can acquire new permissions or new tool paths after the last assessment has already gone stale. That makes continuous governance more important than point-in-time assurance, especially where AI systems connect to identity, secrets, and production data.

For IAM and NHI programmes, the key issue is that AI systems now sit inside access pathways rather than outside them. Once an AI tool or agent can invoke APIs, read data, or trigger workflows, it starts to resemble a non-human identity with governance requirements that exceed a simple pre-deployment checklist.

Key questions

Q: What breaks when AI security is handled only at launch time?

A: Controls go stale as the system changes. New data sources, fine-tuning, prompt updates, and tool integrations can all expand the attack surface after go-live, which means the original approval no longer reflects the current risk. Continuous review is required because AI systems are operationally dynamic, not static software artifacts.

Q: Why do local AI agents complicate identity and access management?

A: They can retain legitimate permissions while changing timing, prioritisation, and action sequence outside human presence. That means the visible identity may remain stable even as the operational behaviour becomes autonomous. IAM teams then lose the simple link between user session, authorisation, and accountability.

Q: How do security teams know if AI governance is working?

A: Look for evidence that access decisions are reviewable, permissions are revocable, and exceptions are not becoming permanent. If the team cannot explain who owns an AI workflow, what it can reach, and when its access was last reviewed, governance is incomplete. Control maturity shows up in traceability, not adoption volume.

Q: Who is accountable when an AI system makes a harmful decision?

A: Accountability should follow the identity chain that authorized, configured, or triggered the action, including the human owner, the platform team, and any delegated agent or tool account. If the organisation cannot name that chain, the governance model is too weak for regulated AI use.

Technical breakdown

Why point-in-time AI risk assessments go stale quickly

AI systems are dynamic in ways most control programmes were not designed for. A model may be retrained, a plugin added, a retrieval source changed, or an agent granted new tool access after the original review. That means the risk profile shifts without a corresponding governance event. Static assessments can document intent, but they do not reliably track operating reality once the system starts interacting with live data, identities, and external services.

Practical implication: treat AI review as a recurring control tied to change management, not a one-off approval gate.

How AI agents change the identity and access model

AI agents are not just analytical systems. When they can query services, move data, and invoke actions, they behave like non-human identities with runtime permissions. Traditional IAM assumes stable roles and bounded human intent, but agents may operate at machine speed, chain actions, and retain access across tasks. That creates a governance problem around privilege scope, delegation, and auditability, especially when the agent’s effective access exceeds what the original workflow required.

Practical implication: map every agent to a governed identity, explicit permissions, and bounded session scope.

Why over-privilege in AI tooling becomes a control failure

The article’s risk pattern is not only model misuse. It is over-privileged access inside AI-connected workflows. If an AI system can reach sensitive systems, read broad datasets, or execute actions without fine-grained limits, the blast radius of prompt injection, misuse, or error increases sharply. In practice, this is an IAM and PAM problem as much as an AI governance problem, because access scope determines how far a compromised or misdirected AI system can go.

Practical implication: reduce AI access to the minimum required APIs, datasets, and actions before scaling deployment.

Threat narrative

Attacker objective: The attacker objective is to exploit AI-connected access paths to influence outputs, extract data, or trigger actions at scale through a trusted system.

1. Entry occurs when an AI system, plugin, or agent is connected to live tools, data sources, or workflows without continuous governance.
2. Escalation follows when that system receives broader permissions than the task requires, allowing it to read, move, or act across sensitive resources.
3. Impact occurs when model manipulation, misuse, or agent error produces data leakage, unauthorized actions, or scaled business disruption.

NHI Mgmt Group analysis

AI governance debt is now an access problem, not just a review problem: the article shows that AI risk keeps changing after launch, which means governance cannot stop at initial approval. Once models, tools, and agents are wired into live systems, the programme inherits identity and access exposure that needs continuous control. That makes IAM and NHI governance part of AI security by default, not by exception. Practitioners should treat every AI integration as a standing control obligation.

AI agents create a new class of non-human identity sprawl: the article’s strongest warning is that agents do not merely consume access, they can accumulate it through workflows, tool calls, and delegated permissions. That is the same structural problem security teams already see with unmanaged service accounts, except the behaviour is more dynamic and faster to drift. The right response is not broader trust, but explicit identity binding, scoped permissions, and audit-ready ownership for every agent.

Continuous assessment is the named concept that matters here: point-in-time review cannot keep up with systems that retrain, reconfigure, or re-delegate after deployment. This is the practical difference between documenting AI risk and governing it. Security leaders should define a continuous assessment loop for AI systems that is triggered by model change, integration change, and privilege change. The control objective is simple: no unreviewed change should expand AI access.

AI security now depends on the intersection of governance and runtime control: WEF-style concern only becomes operationally useful when it is tied to access boundaries, monitoring, and ownership. A programme that cannot say which AI system can access which data, under what delegated authority, will struggle to prove control. Practitioners should align AI oversight with the same discipline used for privileged human and machine access.

The market signal is clear: AI security is converging with identity security: the article reflects a broader shift away from treating AI risk as a separate discipline. The more AI systems act on behalf of users or processes, the more they behave like governed identities that need lifecycle control, least privilege, and evidence of use. The field is moving toward identity-aware AI security, and teams should plan accordingly.

What this signals

Continuous assessment is becoming the minimum viable control for AI-connected systems. Once AI tools, agents, and integrations can change faster than review cycles, governance has to move from annual or launch-based sign-off to event-driven control. That means model changes, connector changes, and privilege changes should each trigger validation, not just documentation.

AI access now needs the same lifecycle discipline as NHI programmes. If an AI system can call tools, read data, or take actions, it should be governed like any other non-human identity with an owner, a scope, and a revocation path. The practical signal for teams is whether they can answer who granted access, who can remove it, and what changed since the last review.

From our research, 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months. That adoption curve suggests AI governance and NHI governance will increasingly share controls, tooling, and reporting. Teams that separate those programmes risk duplicating effort while missing the runtime overlap.

For practitioners

• Tie AI risk reviews to change events Require reassessment whenever a model, plugin, retrieval source, or permission set changes. A review that only happens at launch will miss the control shift created by live integrations and new delegation paths.
• Register every AI agent as a governed identity Assign an owner, a scoped purpose, and a permission boundary to each agent or AI-enabled workflow. Treat tool access, API access, and data access as explicit entitlements that can be reviewed and revoked.
• Reduce standing access before scaling AI use Remove broad read and write permissions from AI systems and limit them to the minimum APIs, datasets, and actions required for the task. That reduces the blast radius of prompt injection and operational mistakes.
• Add runtime monitoring for AI behaviour drift Log tool calls, data retrieval, delegation changes, and unusual action sequences so that misuse can be detected after deployment. Governance evidence should show what the AI system actually did, not just what it was approved to do.

Key takeaways

• AI risk is growing faster than static review models can handle, especially once models and agents start changing after deployment.
• The main governance gap is not awareness but lifecycle control, because access, integrations, and privileges keep shifting in live AI systems.
• Security teams should govern AI agents as non-human identities with continuous review, scoped permissions, and runtime monitoring.

Key terms

• Continuous AI Assessment: A control approach that evaluates an AI system repeatedly as it changes, rather than only before launch. It ties review to model updates, new integrations, permission changes, and observed behaviour so governance stays aligned with the live risk profile.
• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• Permission Drift: Permission drift is the gradual expansion of access beyond what was originally intended. It happens when roles, tokens, and service accounts accumulate unused rights over time, making cloud identities harder to review and more dangerous to compromise.

What's in the full article

AppSOC's full article covers the operational detail this post intentionally leaves for the source:

• The exact breakdown of why the vendor believes AI assessments are not keeping pace with live system change.
• Context on how organisations are shifting from post-incident review toward pre-deployment and ongoing evaluation.
• The article's full discussion of AI agents, over-privileged access, and the operational consequences of delegated tool use.
• The vendor's framing of how security, engineering, and leadership ownership should be aligned for AI risk governance.

👉 AppSOC's full article covers the assessment trend data, AI-specific risk drivers, and the governance gap 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 secrets management. It gives practitioners a practical foundation for controlling non-human access in modern security programmes.