An AI Agent Security Policy: What Belongs In One

Your AI agent can propose moving money, changing a customer record, or touching infrastructure, and its security policy has to say what happens next. It should say which actions are permitted, which need approval, which are blocked, who may change those rules, and what evidence remains after the attempt. OWASP’s AI Agent Security Cheat Sheet says an agent may propose an action, but a policy service or execution component should independently validate scope, privilege, and approval state before execution. That is the centre of the document.

What an AI agent security policy should cover

An AI agent security policy is not just an acceptable-use statement for a model. It is the operating rulebook for agent actions. The distinction matters because an answer in a chat window and a released payment do not create the same risk.

The policy should begin with action categories. Write them in business language. Send refund, delete account record, change customer limit, and open production ticket are better than sensitive operation. A reviewer can test the first set against evidence. The second set becomes a debate.

The next section should state who or what may propose an action, and who or what may permit it. OWASP’s wording is useful because it separates proposal from permission. That separation should appear in the policy text, not only in an architecture diagram.

"The agent can propose an action, but a policy service or execution component should independently validate scope, privilege, and approval state before execution."

— AI Agent Security - OWASP Cheat Sheet Series

Do not overread that sentence. It does not prescribe a named product. It does not say that every agent action must require a human approver. It does say that trusting the agent’s own request as the basis for execution is not enough.

A usable policy then names approval states. The exact states are an organisational choice. The document can still be precise. It can say that a low-value refund is allowed automatically, that a customer-record deletion needs named approval, and that a change to a restricted system is blocked until another route exists. Where the system cannot yet enforce a rule, the policy should say so directly.

That last sentence is not a concession of defeat. It is a defence against false assurance. A policy that says all restricted actions require approval is weak if the agent can still call the tool directly. A policy that says this rule is defined but not yet enforced for this integration gives engineering, risk, and audit a shared defect to close.

The policy also needs a change section. OWASP says structured security testing should occur before an agent is put into use and after material changes to prompts, tools, memory, retrieval, policies, or model providers. That sentence is broader than a model-release checklist, because it includes policy changes and tool changes.

The practical implication is simple. A change to a prompt can change behaviour. A change to a tool can change reach. A change to a policy can change permission. The security policy should treat all of them as changes that may require testing.

The narrower distinction between action permission and general runtime monitoring is easy to blur. The discussion of runtime authorization vs runtime security is useful background for that boundary. Monitoring may tell you that something happened. Permission should determine whether it may happen.

AI agent security and policy management in operation

Policy management is where many drafts become decorative. The document states a rule, but no one can say who owns it, who can change it, how a change is tested, or what happens when the rule conflicts with the current workflow. That is not an AI-specific failure. Agents make it easier to find.

NIST’s discussion of agentic identity places policy management beside agentic identity registries, credentials, rights delegation, and governance. That grouping is useful because it treats policy as part of the operating environment, not as a PDF stored elsewhere.

A security team should therefore put policy ownership in the document. It should name the accountable function, the approval route for changes, and the evidence expected when a rule is changed. If a developer can change the agent’s reach and weaken the test at the same time, the policy has not controlled the change.

"Review test changes carefully; attackers may try to weaken or remove security tests in the same pull request that changes agent behavior."

— AI Agent Security - OWASP Cheat Sheet Series

Again, the quote should not be inflated. It does not say that every code change is malicious. It says the review must be alert to a particular pattern: behaviour changes and test weakening moving together. The policy should make that pattern visible to reviewers.

There is also a timing problem. A policy that is checked only at design review can be bypassed by later changes to prompts, tools, memory, retrieval, policies, or model providers. OWASP’s testing sentence covers those material changes. The policy should turn that into an operational requirement: no material change without a test record, and no test record without the rule version it tested.

That requirement can be applied before enforcement is complete. A team can run a rule in observation, compare the rule’s decision with what the agent actually did, and use the gap as evidence. The article on shadow mode covers that pattern. It is not a substitute for enforcement, but it is better than pretending the rule is live.

The policy should also state what is outside scope. If it does not govern employee use of a public chatbot, say that. If it governs only agents that can act through internal tools, say that. Scope statements are not legal padding; they stop a reviewer from assuming a broader control than the organisation operates.

For enterprises, the difficulty is less the wording than the ownership boundary. The enterprise collection is relevant because agent policy becomes a shared problem across security, platform engineering, risk, and business owners. A draft owned by only one of those groups usually misses the evidence needed by another.

AI agent security standards and what they do not settle

Standards for AI agents can sound more settled than the source material supports. NIST announced the AI Agent Standards Initiative for interoperable and secure innovation. NIST also says it will announce research, guidelines, and further deliverables for that initiative.

"To address this concern, NIST, including CAISI, aims to foster industry-led technical standards and protocols that build public trust in AI agents, catalyze an interoperable agent ecosystem, and diffuse their benefits to all Americans and across the world."

— Announcing the "AI Agent Standards Initiative" for Interoperable and Secure Innovation, 17 February 2026

That is important, but it is not a ready-made corporate policy. It supports the need to track standards work. It does not supply a full action matrix for a bank, insurer, marketplace, or software company.

OWASP has more operational material. OWASP describes the State of Agentic AI Security and Governance as providing a comprehensive view of the landscape for securing and governing autonomous AI systems. OWASP also describes the OWASP Top 10 for Agentic Applications 2026 as a globally peer-reviewed framework that identifies critical security risks facing autonomous and agentic AI systems.

Those documents still do not remove judgement. A framework can tell a team what classes of risk to consider. It cannot know which internal system may release funds, which customer field triggers regulatory reporting, or which record deletion breaks retention duties. The policy has to translate the standard into local action rules.

OWASP says the Agent Control Standard has been donated to the OWASP GenAI Security Project. That statement is a fact about stewardship, not proof that every organisation must adopt a particular implementation. Treat it as another item to track, not as a shortcut around internal risk decisions.

NIST says stakeholders can inform the AI Agent Standards Initiative through responses to a Request for Information on AI Agent Security and to an AI Agent Identity and Authorization Concept Paper. That sentence shows that security, identity, and authorization are being discussed together. It does not give a final rule for your approval workflow.

The right use of standards is therefore disciplined. Cite the source. Extract the control idea. Decide how it applies to a payment release, a record change, or an infrastructure action. Then keep the evidence that the rule was applied.

The article on OWASP’s Agentic Threat Taxonomy and authorization failures is useful when the policy owner needs to connect threat language to permission checks. The article on deterministic policy or LLM-as-judge is useful when the question is what kind of decision record can be defended later.

What this means if you have to produce evidence

A policy is not evidence by itself. It is a promise about how decisions should be made. Evidence is the record that a decision was made that way.

For an AI agent, the evidence burden starts before the action. The record should show the agent identity or source, the requested action, the target system, the relevant rule, the approval state, and the result. The policy should say which of those fields must exist before the action is allowed.

Some organisations will object that they cannot capture all of this yet. That objection is often true. The answer is not to delete the requirement. The answer is to mark the rule as defined, partially evidenced, or not yet enforceable, and to put a date-free owner against the gap.

A disputed action will not be reviewed as a slogan. It will be reviewed as a sequence. What did the agent ask to do. What rule applied. Was approval required. Was approval present. Did the system act. What remains after the fact.

The most fragile evidence is the evidence created only after someone asks for it. Screenshots, chat transcripts, and reconstructed timelines can help an investigation, but they are weak substitutes for a contemporaneous record of the permission decision. The policy should make that distinction clear.

There is another limit. The sources here support independent validation, testing after material changes, careful review of test changes, and active standards work. They do not say that a policy document alone secures an AI agent. A policy without enforcement and records is a management assertion.

A practical build sequence for the policy

1. Define the governed agents. State which agents are in scope, which systems they can reach, and which business actions they may attempt.
2. Write actions in business verbs. Use phrases such as release refund, delete customer record, change limit, and create access request rather than generic risk labels.
3. Separate proposal from permission. The policy should not treat an agent request as permission to act, because OWASP says scope, privilege, and approval state should be independently validated before execution.
4. Name approval states. Define when an action is allowed, when it needs human approval, when it is escalated, and when it is blocked.
5. Attach evidence to each state. For every governed action, say what record must exist before the action proceeds and what record must remain afterwards.
6. Control policy changes. OWASP says structured security testing should occur after material changes to prompts, tools, memory, retrieval, policies, or model providers.
7. Review test weakening. Make reviewers check whether a behaviour change is paired with weaker tests, because OWASP warns attackers may try to remove or weaken security tests in the same pull request.
8. Track standards explicitly. NIST says it will announce research, guidelines, and further deliverables for the AI Agent Standards Initiative, so the policy owner should record which external materials the organisation has chosen to follow.
9. Mark unenforced rules honestly. If a rule is advisory, observed only, or not yet technically enforced, say that in the policy instead of presenting it as a live block.
10. Test one disputed action. Pick a single action that matters and ask whether the organisation can show the request, rule, approval state, result, and surviving record.

The Crelis position is narrow: GREENLIGHT treats sensitive agent actions as permission decisions, and the product demonstration is framed around where AI agents touch money, customers, records, or infrastructure.

Crelis is patent-pending. It holds no SOC 2, ISO 27001 or ISO 42001 certification, and claims none.

Related reading

• Runtime Authorization vs Runtime Security — the boundary between monitoring an action and permitting it.
• Shadow Mode — how to gather evidence before a rule is allowed to block.
• Deterministic Policy or LLM-as-Judge — how to think about decisions that must survive review.
• OWASP’s Agentic Threat Taxonomy and Authorization Failures — how threat language maps to action permission.