Why do organisations need dedicated controls for AI interactions instead of relying on general cybersecurity tooling?

Why This Matters for Security Teams

General cybersecurity tooling still matters, but it was built to watch endpoints, networks, identities, and data flows that are relatively stable. AI interactions add a different trust boundary: prompts can smuggle instructions, model outputs can leak sensitive context, connectors can trigger unintended actions, and embedded secrets can be copied into places that traditional DLP or SIEM rules do not understand. That is why AI-specific controls are becoming necessary rather than optional.

This gap is visible in real-world research. NHIMG’s The State of Secrets in AppSec shows that 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases. That concern is not theoretical. AI systems can expose data through prompts, retrieval layers, tool calls, and generated text even when the surrounding infrastructure appears well defended. Current guidance suggests treating AI interactions as a separate control plane, not just another application log source, and mapping risks to frameworks such as the MITRE ATLAS adversarial AI threat matrix.

In practice, many security teams discover prompt injection, connector abuse, or secret leakage only after the model has already echoed or acted on the sensitive content.

How It Works in Practice

Dedicated AI controls focus on the interaction layer, not just the infrastructure layer. That means inspecting prompts and responses for sensitive data, governing which tools the model can call, and applying policy at runtime based on context such as user role, data classification, task type, and risk score. General controls can still provide logging, network segmentation, and endpoint protection, but they usually do not understand whether a prompt is attempting data exfiltration or whether a tool call is appropriate for that specific agent action.

Practitioners increasingly combine several mechanisms:

• Prompt and response filtering to detect secrets, regulated data, or malicious instructions.
• Connector-level controls to limit which data sources and SaaS actions an AI system can reach.
• Runtime authorisation for tool use, rather than broad pre-approved access.
• Short-lived credentials for AI agents and workflows, so exposure has a limited blast radius.
• Central telemetry for model activity, retrieval events, and tool invocations, so incidents can be reconstructed.

This approach aligns with the growing body of guidance in CISA cyber threat advisories and with NHI research such as OWASP NHI Top 10, which highlights how identity and secret misuse can become AI attack paths. Security teams also use findings from LLMjacking: How Attackers Hijack AI Using Compromised NHIs to understand how exposed credentials can be rapidly abused once AI-linked access is discovered. These controls tend to break down in highly dynamic environments where agents chain multiple tools across SaaS, code, and data platforms because policy enforcement becomes inconsistent across each hop.

Common Variations and Edge Cases

Tighter AI controls often increase operational overhead, requiring organisations to balance safety against workflow friction and model utility. That tradeoff is most visible when teams need to decide how much review to place between the model and high-impact actions such as sending emails, changing records, or retrieving confidential data.

There is no universal standard for this yet, so current guidance suggests calibrating controls to the AI use case. A customer support copilot may need strong content filtering and retrieval restrictions, while an internal coding assistant may need stricter secret scanning, repository allowlists, and stronger audit trails. In some environments, especially those with legacy data stores or broad SaaS integrations, even good AI-specific controls will not fully compensate for poor data hygiene or over-permissioned service accounts. That is why dedicated controls should complement, not replace, identity governance, secrets management, and zero trust principles.

For deeper context on why AI-linked identity risk keeps expanding, NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now and Top 10 NHI Issues are useful references. For implementation detail, the NIST SP 800-53 Rev 5 Security and Privacy Controls remains important, but it does not by itself resolve model-specific abuse paths or prompt-driven data exposure.

Related resources from NHI Mgmt Group

• When should organisations add runtime controls for AI agents instead of relying on monitoring?
• Why do organisations need specialized gateway controls for production AI workloads instead of relying on traditional API gateways?
• Should organisations use a dedicated AI agent identity model or extend current NHI controls?
• Should organisations use security skill prompts instead of access controls for AI agents?