Persistent directives that shape how an AI model should behave across sessions and tasks. In security practice, they act like baseline policy, defining boundaries, refusals, escalation rules, and tool restrictions. They should be versioned, reviewed, and audited because they influence every downstream interaction.
Expanded Definition
System instructions are the persistent rules that shape an AI model’s behaviour across sessions, tools, and tasks. In NHI security, they function as baseline policy for agents, defining what the agent may access, when it must refuse, and how escalation should work.
They are not the same as a one-time prompt or a user message. System instructions sit higher in the instruction stack and can constrain how an autonomous software entity interprets later inputs, including MCP-connected tools, secrets handling, and privileged actions. Definitions vary across vendors on how much persistence, hierarchy, and override capability these instructions actually have, so governance should focus on observable behaviour rather than assumed intent. A clear operating model should also align with security guidance such as the NIST Cybersecurity Framework 2.0, especially around governance, access control, and change management.
The most common misapplication is treating system instructions as a static prompt layer, which occurs when teams copy policy text into production without versioning, review, or testing for tool abuse.
Examples and Use Cases
Implementing system instructions rigorously often introduces a control-versus-flexibility tradeoff, requiring organisations to weigh stronger guardrails against the risk of blocking legitimate agent actions.
- An AI agent that can read tickets but must refuse any request to retrieve secrets unless a privileged workflow approves it.
- A customer-support assistant that is instructed to escalate payments, identity changes, or export requests to a human operator instead of acting autonomously.
- A code-writing agent that may suggest changes but is blocked from executing deployment commands unless a JIT approval step is present.
- A security copilot that can query logs through an MCP server, yet cannot access production secrets because the system instructions prohibit that tool path.
- An internal research agent whose policy requires citing authoritative sources and declining actions that would bypass role-based checks or expose sensitive NHI material.
These patterns are most effective when paired with a documented NHI lifecycle and credential governance process, as described in the Ultimate Guide to NHIs. They also fit broader access-control expectations in the NIST Cybersecurity Framework 2.0, where protective controls should be explicit and auditable.
Why It Matters in NHI Security
System instructions are governance-critical because they can determine whether an agent behaves like a constrained identity or like an overpowered automation endpoint. If they are inconsistent, hidden, or easy to override, the organisation may unintentionally grant broader access than intended, especially when agents are connected to secrets managers, CI/CD systems, or privileged APIs.
NHIs already create material risk at scale: the Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, which broadens the attack surface when agent instructions do not tightly constrain behaviour. That risk is amplified when instruction changes are made informally, because failures often look like ordinary task completion until the agent crosses a boundary. Security teams should therefore treat system instructions as auditable policy artifacts, not just prompt content, and review them alongside identity lifecycle controls and the NIST Cybersecurity Framework 2.0. Organisations typically encounter the impact only after an agent has over-shared, misrouted, or executed an unsafe action, at which point system instructions become operationally unavoidable to address.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | AI-01 | System instructions govern agent behaviour and tool use, central to agentic security. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Instruction-driven access paths can expose secrets and NHI controls if not tightly bounded. |
| NIST Zero Trust (SP 800-207) | 3.1 | Zero Trust requires continuous verification before granting any agent action or resource access. |
Tie agent instructions to least privilege and validate they cannot reach secrets outside approved workflows.
