Software-based authentication can be bypassed, impersonated, or automated more easily than hardware-backed approval. In sensitive AI actions, that weakens assurance that the right human actually authorised the step. It also increases the chance that a compromised session, stolen token, or malicious automation can execute actions without a meaningful verification event tied to the person.
Why This Matters for Security Teams
Software-based authentication is often treated as “good enough” because it is easy to deploy, but sensitive AI actions need stronger assurance than a password prompt, OTP, or approval pushed through a browser session. When an agent can trigger code execution, data export, model changes, or external tool calls, the control must prove more than session continuity. It must prove that the right actor, under the right conditions, approved the exact action.
That distinction matters because AI workflows are high-value and highly automatable. Once a session token, browser cookie, or approval flow is compromised, the attacker does not need to defeat the model itself. They can ride the authenticated session and use the agent’s tool access to move fast. NHIMG research on the DeepSeek breach shows how exposed secrets and mismanaged access can quickly widen blast radius, while the Twitter Source Code Breach is a reminder that access pathways, not just code, determine impact.
In practice, many security teams discover the weakness only after an authorised session has already been reused to execute an action that no human would have intended to approve.
How It Works in Practice
For sensitive AI actions, the control objective is to separate authentication from authorisation and then bind authorisation to the specific action, context, and time window. Software-based authentication can confirm that a user logged in, but it does not reliably establish fresh, high-assurance intent at the moment an agent is about to act. That is why current guidance increasingly favours step-up verification, JIT approval, and short-lived entitlements over persistent trust.
In a stronger pattern, the AI system requests a sensitive operation, such as sending data to an external tool, updating a production prompt, or approving a workflow escalation. The system then evaluates policy in real time using context such as target resource, risk score, session age, device posture, and action sensitivity. If approval is required, the request is re-authenticated through a stronger factor or delegated to a hardware-backed mechanism rather than a simple software prompt. This is closer to the intent of NIST SP 800-53 Rev 5 Security and Privacy Controls, which emphasises strong access control, auditability, and event-specific enforcement.
- Use software authentication for routine access, not for irreversible AI actions.
- Require step-up approval for actions that can exfiltrate data, change policy, or invoke external systems.
- Bind approval to a single transaction or narrowly scoped task, then expire it immediately.
- Log the exact action, context, approver, and downstream tool invocation for later review.
Where this becomes more resilient is in agentic systems that combine policy-as-code with workload identity, so the agent proves what it is while the human approval proves the intent behind a specific high-risk action. These controls tend to break down in highly automated environments with shared sessions, long-lived browser state, or delegated admin tools because the approval event becomes detached from the actual action path.
Common Variations and Edge Cases
Tighter approval controls often increase friction, which means organisations have to balance operational speed against assurance for the subset of actions that truly need it. Best practice is evolving, and there is no universal standard for when software-based authentication alone is sufficient for an AI action.
Low-risk actions, such as non-sensitive content generation or internal drafting, may not justify hardware-backed steps every time. But once an agent can access customer records, production systems, financial workflows, or security tooling, software-only approval becomes fragile. The failure mode is usually not “weak password security” in the abstract. It is token replay, session hijack, or automated abuse of a legitimate approval channel. That is exactly why guidance from ISO/IEC 27001:2022 Information Security Management remains relevant: controls must be proportionate to risk, auditable, and consistently enforced.
In high-volume agent operations, repeated step-up prompts can lead to approval fatigue, so teams sometimes whitelist too broadly. That tradeoff should be treated as a governance decision, not a usability shortcut. For sensitive AI actions, the real question is whether the verification event can still be trusted after compromise, automation, or session theft.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Sensitive AI actions need runtime authorization, not just login. |
| CSA MAESTRO | MG-3 | Addresses governance for agent actions and delegated authority. |
| NIST AI RMF | Trustworthy AI needs accountable, context-aware controls. | |
| NIST CSF 2.0 | PR.AA-01 | Authentication must support strong access assurance for critical actions. |
| NIST Zero Trust (SP 800-207) | SC-23 | Zero trust requires continuous verification, not session trust. |
Require per-action approval checks before any high-risk agent tool call or state change.
Related resources from NHI Mgmt Group
- What breaks when keyword-based DLP is used for conversational AI?
- What breaks when pattern-based AI security is used for agentic workflows?
- What breaks when AI agents are allowed to auto-approve sensitive actions or connect to privileged systems?
- What breaks when password reset workflows do not include fraud detection for phone-based verification?
