Should organisations rely on project rules or runtime policy for agent governance?

Runtime policy should own the guarantee, while project rules should own the guidance. Project rules help the agent behave consistently, but runtime controls define what it can actually do. If the action matters operationally, the enforcement must sit outside the prompt.

Why this choice belongs in runtime policy, not in project rules

Project rules are best treated as operating instructions, while runtime policy is the enforcement layer that can actually block an unsafe or out-of-bounds action. That distinction matters because agent behaviour changes at execution time, when the system can inspect the request, the tool, the target resource and the current context. A rule that lives only in the prompt can guide intent, but it cannot reliably guarantee restraint.

Runtime policy also gives you a cleaner separation between what the team wants the agent to do and what the platform will allow it to do. That matters most when the action has operational side effects, touches sensitive data, invokes external tools, or can create irreversible change. If the decision has to be trusted under pressure, the control needs to sit where execution is approved or denied, not where instructions are merely suggested.

What project rules are good for

Project rules are useful for shaping default behaviour, reducing ambiguity, and making the agent’s task boundaries easier to understand. They can express workflow preferences, tone, escalation expectations, approval paths, and task-specific constraints that help the agent stay consistent across sessions. They are especially valuable when multiple contributors need a shared operating model for how the agent should behave.

They are weaker when the question is whether the agent should be allowed to act at all. A prompt-level rule can be skipped, weakened by conflicting instructions, or interpreted differently across contexts. That makes project rules suitable for guidance and consistency, but not for authoritative protection of tools, credentials, data access, or privileged operations.

How to split guidance from enforcement in practice

Use project rules to define intent, preferred workflows, and the kinds of actions that should trigger review. Use runtime policy to enforce access boundaries, per-action approval, and hard stops for disallowed operations. In practice, that means the same control objective should appear twice, once as instruction and once as enforcement, but only the runtime layer should be considered authoritative.

The strongest pattern is to let the project rules describe the operating norm and let the runtime layer verify the current principal, requested action, target system, and expected impact. That approach keeps the agent flexible for low-risk work while still preventing it from exceeding its authority. It also makes exceptions easier to reason about, because you can see whether a failure came from bad instruction, bad policy, or both.

Risk and Threat Considerations

Prompt-only governance creates a false sense of control, especially when an agent can call tools, access systems, or carry out actions that affect production. If the enforcement point is not outside the prompt, an injected instruction, a conflicting objective, or a simple model mistake can turn guidance into unauthorised behaviour.

Failure mechanism: The agent follows text rules that are advisory rather than enforceable, so a higher-risk action can proceed when the prompt is overridden, misunderstood, or bypassed through a tool chain or delegated workflow.

Impact: Unsafe actions may be executed with real privileges, which can lead to data exposure, incorrect system changes, abuse of connected tools, or loss of auditability over who allowed what.

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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Agent authority must be enforced outside the prompt to prevent overreach.
	ASI02 — Tool Misuse	Runtime policy is needed to stop unsafe tool invocation despite advisory rules.
Recommendation — Enforce per-action policy checks before any privileged agent action. Gate tool calls with policy decisions at execution time.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	The question is about constraining what an agent can actually do at run time.
	IA-5 — Authenticator Management	Runtime enforcement often depends on controlling credentials and their use.
	AU-2 — Event Logging	Runtime governance needs records of denied and allowed agent actions.
Recommendation — Restrict agent permissions to the minimum needed for each task. Manage credentials so prompt text cannot expand effective access. Log agent decisions and enforcement outcomes for review.

Practitioner Guidance

What to verify: Confirm that any action with operational impact is mediated by an enforceable decision point, not just by prompt text. If the agent can cause change, the platform should be able to deny the request even when the prompt says yes.

Decision rule: If a rule exists to prevent harm, treat it as incomplete unless the control can still hold when the prompt is ignored, contradicted, or manipulated. If the consequence is business or security relevant, the enforcement must be external to the model.

Practitioner takeaway: Use project rules to shape behaviour, but rely on runtime policy to make authority real, because only the runtime layer can consistently bound what the agent is allowed to do.