How should security teams define what AI systems can and cannot do in the enterprise?

Security teams should define AI policy around permitted, restricted, and prohibited uses based on data sensitivity, tool type, user role, and decision impact. The policy should also specify what actions an AI system may take, what it may infer, and when human approval is required. That makes the policy enforceable in practice, not just a tool approval list.

Why This Matters for Security Teams

Defining what AI systems can and cannot do is not just a governance exercise. It determines whether a model can access sensitive data, trigger business actions, or influence decisions that carry legal, financial, or safety impact. A policy that only approves a tool without restricting its permissions, inputs, outputs, and escalation paths leaves a large gap between intention and operation. Current guidance across NIST Cybersecurity Framework 2.0 and AI risk practice points toward control definition, accountability, and continuous review rather than one-time approval.

The practical issue is that enterprise AI is rarely passive. It can retrieve content, summarize records, draft recommendations, call APIs, or initiate workflows through connected tools. That means “can do” and “cannot do” must be defined in operational terms, not vague policy language. Security teams should tie those boundaries to data classification, identity, privilege, and the downstream effect of the action. If a model can only read low-sensitivity content, that is a very different risk posture from a system that can submit tickets, update records, or approve transactions.

In practice, many security teams encounter overreach only after an AI system has already been connected to data or tools without clear guardrails.

How It Works in Practice

A workable AI use policy usually starts with a control matrix that links system capability to business context. That matrix should answer four questions for each use case: what data the system may ingest, what sources it may reach, what outputs it may generate, and what actions it may take without human intervention. For systems with tool access, the boundary must include API calls, write actions, external sharing, and privilege escalation paths. If the question involves agentic systems, the policy should also define when an AI agent may act autonomously and when it must stop for approval.

Security teams should separate policy into three tiers: permitted, restricted, and prohibited. Permitted uses are low-risk and well understood. Restricted uses are allowed only with controls such as logging, approvals, redaction, or limited datasets. Prohibited uses include situations where the model would make high-impact decisions alone, expose regulated data, or execute irreversible actions. That approach aligns well with the risk-based structure in NIST Cybersecurity Framework 2.0 and the governance emphasis in OWASP Top 10 for Large Language Model Applications.

• Define the AI system’s role: assistant, summariser, analyst, or action-taking agent.
• Classify the data it may read, retain, and reuse.
• Restrict tool access by function, environment, and privilege level.
• Require approval for high-impact outputs or irreversible actions.
• Log prompts, tool calls, outputs, and human overrides for auditability.

This policy also needs ownership. Every AI system should have a named business owner, a technical owner, and a control owner so that exceptions, reviews, and incidents are not handled informally. Where AI connects to non-human identities or service accounts, those credentials should be governed separately rather than embedded in the policy as an afterthought. These controls tend to break down in highly integrated environments where AI agents can chain multiple tools across SaaS platforms because the permission boundary becomes difficult to see and harder to audit.

Common Variations and Edge Cases

Tighter AI restrictions often increase friction, requiring organisations to balance speed and automation against governance and liability. That tradeoff is especially visible when teams want rapid adoption of copilots or autonomous agents but still need defensible control over sensitive workflows. Best practice is evolving, and there is no universal standard for every enterprise scenario yet.

One common edge case is decision support versus decision making. A model that drafts a recommendation may be acceptable, while a model that approves a credit limit, hires a contractor, or changes a production control may not be. Another is data transformation: a system that only summarises may still be risky if it can infer protected attributes, hidden relationships, or confidential intent from apparently harmless inputs. That is why “cannot infer” should appear in policy alongside “cannot access.”

Agentic systems create a further boundary problem because the model may not need broad data access if the tools themselves are powerful. In those cases, the policy should focus on permitted actions, approved tool chains, and explicit human checkpoints. Where the enterprise uses retrieval or external knowledge sources, the team should also define what content may be pulled into context and whether the AI output needs validation before business use. The current consensus is that policy should be capability-based, not chatbot-based. For systems that operate inside regulated or high-trust environments, this is where alignment with NIST Cybersecurity Framework 2.0 remains useful, but implementation details still depend on the organisation’s risk appetite and control maturity.

Related resources from NHI Mgmt Group

• How should security teams govern AI agents that can access enterprise systems?
• How should security teams defend enterprise AI systems against jailbreak attacks?
• How should security teams govern AI data labeling in enterprise AI systems?
• How should security teams authenticate AI agents in enterprise environments?