What breaks when an AI system can both respond and initiate work?

The control model breaks if it assumes identity actions only happen after a human asks for them. Reactive and proactive systems can create, modify or escalate identity-related work before a person intervenes, so the governance boundary has to move to the trigger itself.

When response and initiation happen in the same system, what boundary actually fails?

The failing boundary is the assumption that identity-governed work only starts after a human request. Once an AI system can both answer and initiate actions, it can create, update, route, or escalate identity-related work on its own trigger. That means governance has to follow the system’s trigger and authority model, not the human conversation alone.

In practice, this changes the control question from “Who asked?” to “What is allowed to happen when the system decides a step is needed?” That is why agentic workflows need explicit rules for delegation, approval thresholds, and ownership of side effects. The work itself may still be useful, but its initiation path is now part of the control surface.

For practitioner context, the trigger can be a model inference, a tool call, a workflow rule, or a stored state transition. The important distinction is whether the system can initiate identity-bearing changes such as provisioning, revocation, credential handling, or access escalation without a person first opening the door.

Why do reactive and proactive AI behaviours change identity governance?

Reactive systems wait for prompts; proactive systems can observe conditions and act before a user intervenes. That difference matters because identity work often carries irreversible effects, such as granting access, rotating secrets, or changing privileges. A system that can both respond and initiate can therefore move from assistant to actor, which changes accountability and audit expectations.

This is especially important when the system is allowed to touch workflows that affect access decisions or security posture. A simple answer-generation model can be reviewed like a knowledge tool, but a system that can also open tickets, trigger approvals, or modify entitlements needs stronger guardrails around intent, authority, and traceability. NHIMG’s Agentic AI Compliance Guide is relevant here because it frames governance, evidence, and oversight for systems that can act as well as respond.

The practical shift is that every initiated action must be treated as a governed event, not just a downstream convenience. If the AI can start the work, then the review point is no longer only the final approval step, it is the permission to initiate the workflow in the first place.

Which control assumptions stop holding once the system can initiate work?

Three assumptions usually break first. The first is that human intent is always present at the start of the workflow. The second is that approvals happen before meaningful side effects. The third is that identity-related operations are only administrative when a person explicitly requests them. In an initiator-capable system, those assumptions are too narrow.

The right control model has to separate suggestion, initiation, and execution. A system may be allowed to recommend a change, create a draft action, or request approval, but not all three. When those layers blur, a model can accidentally cross from analysis into authority. This is why zero standing privilege and explicit least-privilege design matter even for AI-driven workflows: the system should only have the power needed for the specific state it is allowed to reach.

Technical teams should also think about escalation paths. If an AI can start work that later leads to access changes, then the escalation path itself must be logged, bounded, and attributable. Useful external reference points for this include NIST Cybersecurity Framework 2.0, NIST SP 800-53 Rev. 5 Security and Privacy Controls, and NIST AI Risk Management Framework, because they help frame governance, control, and accountability across the action path.

How should practitioners redesign governance for systems that can both answer and act?

Start by classifying which actions the AI may initiate, which actions require human approval, and which actions are prohibited altogether. Then tie those rules to observable triggers, not just user prompts. That means the system should be evaluated on the event that causes action, the scope of the action, and the evidence left behind.

What to verify: Confirm that the AI cannot move from recommendation to execution without a control point that is visible to operations and security. Check that initiated work is attributed to a system identity, routed through an approval boundary when needed, and recorded with enough context to reconstruct why it started.

Common mistake: Treating the conversational interface as the whole control boundary. The real boundary is the combination of trigger, authority, and effect, so a safe-looking chat layer can still mask an unsafe action layer.

Practitioner takeaway: If the system can initiate work, governance must be written around the action it can cause, not the human prompt it may or may not receive first.

Practitioner takeaway: The safest design is not “AI that never acts”, it is AI whose initiations are narrow, observable, and reversible enough to survive audit and incident review.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Agent-initiated work can cross into unauthorized identity actions.
	ASI01 — Agent Goal Hijack	Proactive action can diverge from the intended user goal or trigger.
Recommendation — Constrain agent authority so initiated identity changes require explicit approval and auditability. Bind agent actions to approved goals and block unsanctioned workflow initiation.
NIST AI RMF	GOVERN — Govern	The question is about governing when an AI may initiate action and who owns it.
Recommendation — Define accountability, escalation, and approval rules for AI-initiated work.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Initiating work requires tightly bounded authority to prevent overreach.
	AU-2 — Event Logging	Initiated actions need traceable evidence of what started, why, and by whom.
Recommendation — Limit the system to the minimum permissions needed for its allowed actions. Log AI-initiated actions with enough detail to reconstruct trigger and effect.