Rules of Engagement for AI Agents

Thesis

Cybersecurity teams are beginning to connect AI agents to SIEM platforms, endpoint tools, vulnerability scanners, identity providers, cloud consoles, ticketing systems, and incident-response workflows.

That changes the security problem.

A chatbot can produce a bad answer. An agent can use credentials, select tools, retrieve sensitive information, modify records, and change the state of an operational system.

The central question is no longer only whether the model is accurate or resistant to prompt injection. It is whether the system has more authority than its mission, evidence, and controls can justify.

Existing security controls remain necessary, but they do not answer every agentic question. Identity and access management may determine whether an agent can call an endpoint-isolation API. It does not necessarily determine whether isolation supports the current mission, whether the evidence is sufficient, whether a human must approve the action, or whether the agent should stop.

This paper proposes Agent Rules of Engagement, or Agent ROE, as a mission-level operating contract for AI agents used in cyber operations.

Evening Star thesis: Capability is not authority. An AI agent should receive only the bounded, observable, and evidence-backed authority required for its mission.

From Assistance to Authority

The security impact of an AI system depends less on what it is called than on what it can affect.

An agent may have a goal, memory, credentials, tools, planning logic, and permission to act repeatedly until it believes the task is complete.

The relevant security boundary is therefore the entire workflow:

Intent → context → reasoning → identity → tool → action → outcome

A malicious document may alter the agent’s plan. A broad service account may turn a triage task into a production change. A legitimate tool may be used for the wrong purpose.

Prompt injection remains important, but it is only one path into the system.

Prompt injection is an entry point. Authority determines the blast radius.

Current OWASP work on agentic security increasingly treats tools, identity, context, runtime policy, and traceability as part of the security boundary. NIST similarly emphasizes operational AI risk management through testing, evaluation, verification, and validation.

The Agent ROE Card

The Agent ROE Card defines the operating boundaries for a specific agent, workflow, and environment.

If one of these elements is undefined, the agent is not ready for consequential access.

A weak mission might say:

Investigate suspicious activity.

A stronger mission would say:

Correlate evidence related to designated high-severity endpoint alerts for corporate workstations during the previous 24 hours and produce a recommendation for a Tier 2 analyst.

The stronger mission identifies the alert class, asset class, time window, expected output, and human recipient. It also creates a basis for determining when the agent has completed the task or moved beyond it.

Scope should be an allowlist, not an aspiration.

An agent authorized to search one SIEM workspace should not assume permission to inspect every connected tenant. An agent assigned to corporate workstations should not expand into operational technology, customer environments, critical servers, or unrelated identities.

Data and Tool Boundaries

Cyber agents may consume internal telemetry, threat intelligence, email, tickets, analyst notes, websites, uploaded files, and outputs from other AI systems.

Those sources do not deserve equal trust.

A threat-intelligence report may be credible about an indicator while remaining untrusted as a source of instructions.

The governing principle is:

Retrieved content may inform the mission. It may not redefine the mission.

Tool access should also be narrowly defined. The ROE should specify:

• Which tools are approved.
• Which functions may be called.
• Which arguments and targets are permitted.
• Which destinations may receive data.
• Which identity the agent will use.
• How long the credentials remain valid.
• Whether the action is read-only, reversible, privileged, or destructive.

Read and write access should be separated wherever practical. An agent that can query an endpoint should not automatically receive permission to isolate it.

The Authority Ladder

Authority should be assigned per action rather than once for the entire agent.

A vulnerability-management agent may correlate scanner findings, asset importance, exploit context, and control coverage. It may prepare remediation tickets. It should not automatically accept business risk or patch production.

A threat-hunting agent may run approved read-only searches. It should not isolate a host merely because one hypothesis appears plausible.

An incident-response agent may build a timeline and prepare a containment plan. Actions affecting privileged identities, critical assets, or production availability should require stronger approval.

The question is not whether agents should ever act. The question is whether the action is sufficiently bounded, evidenced, reversible, observable, and authorized.

Human Approval and Stop Conditions

Human approval is not a meaningful control when the operator sees only a recommendation and an Approve button.

A useful approval request should identify:

• The proposed action.
• The affected target.
• The supporting evidence.
• Missing or conflicting evidence.
• The expected operational effect.
• The risk of acting.
• The risk of not acting.
• Whether the action can be reversed.

Approval should be bound to a specific action, target, argument set, and time window. Approval to isolate one workstation should not become standing permission to isolate any endpoint.

The ROE must also define when the agent should stop.

Common stop conditions include:

• The target falls outside scope.
• Required evidence is absent or stale.
• Evidence materially conflicts.
• Retrieved content attempts to issue instructions.
• A tool or schema changes unexpectedly.
• The agent requests additional privilege.
• A human approval is missing or expired.
• The action cannot be safely reversed.
• The policy or audit service is unavailable.

A stop condition should pause the workflow, block further consequential tool use, preserve the evidence, revoke temporary credentials where appropriate, and notify the designated human owner.

For consequential actions, ambiguity should reduce authority—not increase autonomy.

Enforcing ROE in the Architecture

Agent ROE should not exist only as a document or system prompt. It should be enforced in the execution path.

A simple control pattern is:

Operator → Agent → ROE Policy Layer → Tool Broker → Operational System

The agent proposes an action. The policy layer evaluates the mission, target, evidence, authority level, and approval state. The tool broker exposes only the permitted capability and supplies narrowly scoped credentials.

The policy decision should return one of four outcomes:

• Allow
• Deny
• Modify
• Approval required

Supporting controls should include:

• A dedicated agent identity.
• Least-privilege and short-lived credentials.
• Separate read and write tools.
• Argument and destination validation.
• Action and cost limits.
• Structured audit records.
• Runtime monitoring.
• Rollback and recovery procedures.

A system prompt such as “never perform dangerous actions” may influence model behavior, but it is not an authorization boundary.

The model may propose. The control plane disposes.

Applying ROE to Cyber Operations

The framework should produce different authority profiles for different workflows.

Consider an endpoint-triage agent.

Its mission is to review designated high-severity alerts and produce an evidence-backed recommendation. It may read from the SIEM, EDR, asset inventory, and identity provider. It may create a draft incident.

It may not use a shell, send external messages, isolate a host, or modify an identity.

A Tier 2 analyst may approve workstation isolation. An incident commander must approve actions affecting privileged identities or critical systems.

The agent must stop when the asset is outside scope, telemetry is missing, evidence conflicts, a tool requests additional privilege, or retrieved content attempts to reshape the mission.

This agent remains useful. It reduces analyst research time, correlates evidence, and prepares the case. The ROE does not prevent automation. It prevents useful automation from silently becoming unauthorized consequence.

Minimum Release Gate

A consequential cyber agent should not enter production unless:

1. Its mission and scope are documented.
2. Its data sources and tools are approved.
3. Its authority is defined per action.
4. Its human-approval requirements are testable.
5. Its stop and recovery behavior has been exercised.
6. Its actions and outcomes can be reconstructed.
7. Its regression and adversarial evaluations pass.
8. Its ROE has an owner, version, and expiration date.

Every serious production failure should become a permanent evaluation case. Every material change to the model, prompt, tool set, identity, policy, or data source should trigger reassessment.

This follows the broader Evening Star position that agents must be tested across the complete task loop—context, tools, policy, approvals, recovery, and final outcome—not only on the quality of their final response.

Closing

Cyber agents will become more useful as they gain access to better evidence, more tools, longer-running workflows, and stronger reasoning.

Those same capabilities increase the consequence of error, manipulation, excessive trust, and unauthorized action.

The answer is not to prohibit agents from operating. It is to make their authority explicit.

Before connecting an AI agent to a cyber workflow, ask:

• What mission is it serving?
• What is in scope?
• Which evidence may it trust?
• Which tools may it use?
• What may it do without approval?
• When must it stop?
• Can every consequential action be reconstructed?

Capability gets an agent into the workflow. Rules of engagement determine whether it belongs there.

Every consequential action needs a boundary, a gate, and a trace.

The goal is controlled, observable, and defensible autonomy.

References

1. OWASP GenAI Security Project. Agentic application security and the Agent Control Standard.
2. NIST AI Resource Center. AI Risk Management Framework resources and testing, evaluation, verification, and validation guidance.
3. Evening Star AI. Red Teaming Agentic AI Systems.
4. Evening Star AI. Practical Evals for Agentic Systems.
5. Evening Star AI. MCP Security and Tool-Space Governance.