Define AI as advisory unless the transaction has been explicitly governed for automation. AI can assist with discovery and comparison, but payment, passport data, and booking commitments should require controlled authorisation, auditability, and a clear human override path.
Why This Matters for Security Teams
Customer journeys now mix search, identity checks, recommendations, payment, support, and post-sale service, which means AI may be exposed to decisions that have legal, financial, or privacy impact. Security teams cannot treat every AI action as harmless because a recommendation engine, chatbot, or agentic workflow can cross from guidance into execution very quickly. That shift changes the control objective from content safety to authorisation, traceability, and change management.
The practical issue is not whether AI can answer questions, but whether it can trigger actions that create commitments on behalf of a customer or the organisation. Current guidance suggests that high-impact steps should be governed with the same discipline used for other privileged workflows, including approval boundaries, logging, and rollback paths. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it maps well to authorisation, audit, and accountability expectations.
In practice, many security teams encounter the boundary only after an AI assistant has already drafted, initiated, or confirmed an action that should have required explicit approval.
How It Works in Practice
Security teams usually decide AI boundaries by classifying journey steps into advisory, assisted, and autonomous modes. Advisory means the AI can explain, compare, or recommend. Assisted means the AI can prepare a transaction, but a person still approves it. Autonomous means the AI can execute without a human in the loop, which should be rare and tightly constrained. The key is to define these modes per journey step, not per application, because the same system may be safe for FAQ support but not for payment, identity proofing, or booking commitments.
A workable pattern is to link AI permissions to business risk, data sensitivity, and reversibility. If the action can create a legal obligation, move regulated personal data, or alter a customer account, the AI should not be the final decision-maker unless the workflow has been explicitly approved, tested, and monitored. Teams should also require an immutable audit trail showing what the AI saw, what it suggested, who approved it, and what was actually executed. That becomes essential for incident response and customer dispute handling.
- Limit AI to read-only or recommendation mode by default.
- Require step-up approval for payments, account changes, and identity updates.
- Use policy checks before execution, not only after output generation.
- Log prompts, tool calls, approvals, and final actions together.
- Provide a clear human override and kill switch for operational failures.
For digital identity and authentication steps, teams should also align to NIST SP 800-63 Digital Identity Guidelines so the AI does not weaken identity proofing or session assurance. For AI-specific governance, NIST AI Risk Management Framework helps define who owns the risk and how output quality is monitored. These controls tend to break down in highly orchestrated journeys with multiple back-end systems because the AI may appear to be advisory while still triggering downstream automation through APIs.
Common Variations and Edge Cases
Tighter control often increases friction and operational overhead, requiring organisations to balance customer experience against misuse, error, and compliance exposure. That tradeoff is most visible in journeys where the customer expects speed, such as travel, retail, or service recovery. In those cases, best practice is evolving toward tiered authority rather than an all-or-nothing model.
One edge case is low-risk, reversible automation. For example, an AI may be allowed to re-order information, suggest next steps, or pre-fill a form if the final submission remains human-approved. Another is delegated business authority, where a clearly scoped internal AI agent can act within a policy envelope, but only after separation of duties and strong monitoring are in place. There is no universal standard for this yet, so organisations should document local risk acceptance rather than assume industry consensus.
Teams should be especially cautious where AI touches identity verification, payment, or regulated data across vendors. If a journey includes SSO, KYC, or shared customer profiles, the AI boundary must be consistent across all connected systems, not just within the front-end experience. The same is true for multilingual or high-volume support channels, where a persuasive assistant may be mistaken for an authorised representative unless disclosures and controls are explicit. In practice, the hardest failures happen when the AI is technically “advisory” but operationally trusted as if it were authorised.
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 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF, NIST SP 800-63 and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Access control is central when AI may initiate customer journey actions. |
| NIST AI RMF | GOVERN | Governance determines who owns AI decisions and acceptable autonomy. |
| OWASP Agentic AI Top 10 | A2 | Agentic systems can overreach into unauthorized actions in user journeys. |
| NIST SP 800-63 | IAL/AAL | Identity assurance matters when AI touches verification or account changes. |
| NIST AI 600-1 | GenAI profiles stress output controls and human oversight for customer-facing use. |
Treat customer journey AI as governed assistance unless explicit control and monitoring exist.
Related resources from NHI Mgmt Group
- How should security teams prove DORA compliance for AI agents that act autonomously?
- How should security teams govern AI assistants that can act inside IAM systems?
- How should security teams govern MCP-enabled AI assistants that can act on tools and data?
- How should security teams decide whether an AI agent gets human or non-human identity?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
