A written control that sets clear boundaries for where AI may operate and where it must not. In regulated environments, this is the first line of defence against unsafe data exposure, unapproved action, and workflow drift.
Expanded Definition
A Permitted And Prohibited Use Policy defines the approved contexts, tasks, data types, and user groups for AI use, alongside explicit boundaries for situations that are disallowed. For NHI Management Group, the policy matters because it turns broad AI adoption into a governed control surface rather than an open-ended permission to experiment. It is not the same as a general acceptable use policy: this document is usually narrower, more operational, and more closely tied to model access, prompts, outputs, and downstream actions.
Industry usage is still evolving, so definitions vary across vendors and legal teams. Some organisations treat the policy as a compliance artifact, while others use it as an operational guardrail for model routing, prompt filtering, and human approval thresholds. A strong version of the policy should describe what the AI can handle, what it must refuse, what escalation is required, and which data classes are out of bounds. That makes it a practical control for AI governance, especially where NIST Cybersecurity Framework 2.0 principles are being applied to AI-enabled processes.
The most common misapplication is treating the policy as a generic ethics statement, which occurs when teams publish broad principles but do not define concrete operational restrictions for specific tools, workflows, and data sets.
Examples and Use Cases
Implementing Permitted And Prohibited Use Policy rigorously often introduces friction in day-to-day workflows, requiring organisations to weigh speed and autonomy against better control and auditability.
- An internal support assistant is allowed to summarise public knowledge articles but prohibited from ingesting customer identity documents, contracts, or secrets.
- A software engineering copilot may be permitted to generate test code, but prohibited from making production changes without review and approval.
- A finance chatbot may answer policy questions, yet prohibited from giving investment advice or acting on behalf of a user.
- An AI agent with tool access may draft a ticket or trigger a workflow, but prohibited from executing payments, deleting records, or changing access rights without explicit human confirmation.
- A regulated enterprise may allow NIST Cybersecurity Framework 2.0-aligned logging and review for all AI outputs while prohibiting retention of sensitive prompts in uncontrolled collaboration tools.
These examples show that the policy is most useful when tied to real system behaviour: input sources, model scopes, tool permissions, and review steps. Where the policy is vague, teams tend to assume that “approved for business use” means “approved for any business action,” which is rarely true.
Why It Matters for Security Teams
Security teams rely on this policy to reduce the chance that AI systems become shadow operators, handling data or actions they were never meant to touch. Without clear permitted and prohibited use boundaries, organisations can expose personal data, secrets, regulated content, or internal workflows to tools that are not designed for those purposes. The risk increases when AI is connected to identity systems, ticketing platforms, source code repositories, or agentic workflows with execution authority.
This term is especially important for NHI governance because AI agents often authenticate through service accounts, API keys, and other non-human identities. If the policy does not specify which identities may be used, for what actions, and under what approvals, the organisation can create durable access paths that outlive the business need. That is how a convenience layer becomes a control failure. Strong policy design should therefore sit alongside access review, logging, data classification, and escalation rules, not replace them.
Organisations typically encounter the consequences only after an AI system has already exposed data, taken an unintended action, or operated outside its intended workflow, at which point the permitted and prohibited use policy becomes operationally unavoidable to fix.
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 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RR-01 | Defines governance roles and responsibilities that support policy ownership for AI use boundaries. |
| NIST AI RMF | Frames AI risk governance, including policies that constrain harmful or out-of-scope system use. | |
| OWASP Agentic AI Top 10 | Covers agent misuse and unsafe tool actions that permitted use policies should restrict. |
Assign a clear owner for AI use policy decisions and review them through governance routines.
Related resources from NHI Mgmt Group
- How should organisations enforce AI policy compliance across employee and agent use?
- Should organisations use breach monitoring before changing password policy?
- Should organisations use the same policy model for humans and non-human identities?
- What do teams get wrong when they use identity claims as access policy?
