Who should own governance when AI and agentic systems are used in deception operations?

Who should own governance for AI-led deception operations?

Governance should sit with security leadership, but it cannot be owned by one function alone. Deception operations that use AI or agentic systems change the operating model because they introduce machine-generated actions, identity decisions, and live-response judgments into an attacker-facing workflow. That means the owner must be accountable for policy, approval boundaries, auditability, and escalation paths, while SOC, identity, and risk functions each control part of the execution.

In practice, the governance failure usually appears when teams treat the system as a tooling question instead of a decision-rights question.

NIST AI Risk Management Framework is useful here because it frames AI as a governed system of roles, risk tolerances, and lifecycle responsibilities rather than a standalone capability. For deception use cases, that distinction matters: if the system can generate lures, trigger responses, or adapt behavior, the organisation must decide who can authorise those actions, who can stop them, and who is accountable when the system’s output crosses a boundary.

What governance needs to cover in agentic deception workflows

Agentic deception workflows are operationally different from static honeypots or scripted decoys because the system may choose actions, assemble content, or respond to attacker behaviour. Governance therefore needs to define the decision surface, not just the technology stack. A useful model separates policy ownership, operational ownership, and evidentiary ownership.

• Policy ownership defines what the system may do, what data it may use, and where human approval is required.

• Operational ownership defines who tunes prompts, tools, guardrails, and escalation logic during live use.

• Evidentiary ownership defines who preserves logs, prompts, outputs, and analyst review records for audit and incident review.

The practical control point is not whether AI is present, but whether the deception action can affect an adversary interaction, an internal identity, or an incident workflow without review. That is why SOC teams usually own day-to-day execution, identity teams own any synthetic or delegated identity interactions, and risk or legal owners define acceptable use and exception handling. Where the system can create autonomous actions, governance also needs explicit stop conditions and reviewable outputs.

OWASP Top 10 for Agentic Applications 2026 is relevant because it highlights the governance implications of tool use, delegated action, and control failure in agentic systems. That is especially important in deception, where a harmless-looking automation can become a control breach if it acts outside its intended scope.

The guidance breaks down when an organisation cannot separate approved deception actions from general SOC automation, because the same autonomy that improves realism can also erase accountability.

Where ownership gets blurred and why that matters

Tighter governance often slows experimentation, so organisations have to balance faster deception tuning against stronger approval and traceability requirements.

One common blur is between “who runs the system” and “who accepts the risk.” Those are not the same. The team operating the platform may understand the mechanics, but the function that owns the risk tolerance must decide whether the deception approach is acceptable, especially if it uses synthetic identities, autonomous replies, or dynamic targeting. Another blur appears when red team, SOC, and engineering each assume someone else is responsible for content safety, boundary testing, or post-action review.

There is no universal consensus on whether AI deception should sit in security operations, an AI governance office, or a dedicated response engineering function. The better practice is to make security leadership the accountable owner and assign explicit sub-ownership for identity risk, model or agent behavior, and incident evidence. That keeps the decision rights clear when deception output affects live attacker interactions, analyst judgment, or internal trust decisions.

MITRE ATLAS adversarial AI threat matrix is a good reference point when the deception workflow itself may become a target for manipulation, prompt abuse, or tool-path exploitation. In those cases, governance is not just about authorisation, but about defending the deception system from being turned into an attacker-controlled channel.

Practitioner takeaway: the right owner is the function that can set and enforce boundaries, not the function that merely deploys the tooling, and that distinction becomes critical once autonomous responses can influence live adversary engagement.

Related resources from NHI Mgmt Group

• What makes agentic AI an NHI governance issue?
• Why is NHI governance critical in the age of AI attacks?
• Why is single-provider AI agent governance not enough for enterprise security?
• Why is visibility important in AI governance?