ESSAF

Thesis

Artificial intelligence is moving beyond answering questions. Agents can interpret objectives, select tools, retrieve information, coordinate work, and interact with operational systems. That changes the security problem from evaluating an answer to governing a sequence of actions.

For blue teams and cyber practitioners, the opportunity is practical: connect records, develop investigative leads, explain unfamiliar results, and prepare findings that people can inspect. The risk is equally practical. An agent may mistake evidence for instructions, use a legitimate tool for an unauthorized purpose, or continue working after its assignment should have ended.

Better reasoning does not resolve those questions. Neither does a system prompt asking the agent to behave responsibly.

This paper proposes Evening Star Secure Agent Framework (ESSAF) as a reusable framework for agents operating under explicit authorization. It develops the Agent Rules of Engagement model into an architecture for bounded workflows, independent authorization, controlled tool execution, and reconstructable evidence, with support for self-contained local operation. [1]

The intended audience includes blue teams, incident responders, threat hunters, security engineers, vulnerability analysts, and other cyber practitioners using AI for operational work. The framework is not tied to a particular organization, sector, team structure, or assignment. Its controls should apply across these workflows while reflecting each environment's authorized scope and operational risk.

The design priorities are self-contained operation, model independence, enforceable authority, evidence-grounded analysis, human oversight, and operational resilience.

Evening Star thesis: Agent intelligence should determine what a system can recommend. Explicit authorization must determine what it is allowed to do.

From Agent Capability to Operational Trust

Consider an agent reviewing authentication records. It identifies repeated connection attempts, compares them with a baseline, and recommends a closer investigation. That is useful analytical work.

Now give the same agent credentials that can disable accounts, isolate endpoints, or modify network controls. Its next decision can affect operations rather than merely describe them.

The relevant questions become specific. Which assets are authorized? What evidence supports the action? Who owns the operational decision? Does the approval remain valid? What happens when a tool times out or the agent encounters contradictory information?

Identity and access controls remain necessary, but the ESSAF proposal also binds access to a particular assignment. Possessing a credential is not sufficient evidence that every action available through that credential is authorized for the current task.

This distinction also applies to multiple agents. Dividing an investigation among specialists may help organize the work, but it must not distribute unrestricted authority. A delegated task should carry a bounded purpose and evidence references, not inherit every capability available to the platform.

Operational trust is therefore a property of the complete workflow: the assignment, context, identities, tools, approvals, execution, and observed outcome. It is not a property conferred by the model's confidence.

Build on Existing Frameworks, Not Around Their Limits

Existing frameworks provide useful foundations. LangGraph supports stateful orchestration, persistence, and human intervention. PydanticAI provides typed model interfaces, structured outputs, dependencies, and testing support. CrewAI offers role-oriented collaboration through agents, tasks, crews, and flows. Their capabilities overlap; these descriptions identify useful design patterns rather than exclusive features. [2–4]

ESSAF should reuse these capabilities without treating any agent library as the source of operational authority.

This is not a proposal to stack several complete agent frameworks together. Competing execution loops, duplicate memory systems, and overlapping retry behavior would make the system harder to reason about. ESSAF should define clear interfaces and keep its dependency set small.

Typed validation can establish that a request has the required fields. It cannot establish that the evidence is true or that the action is authorized. Likewise, a workflow pause is useful only when protected execution paths actually stop.

ESSAF's proposed contribution is the integration of operational authority, execution control, and evidence—not a claim that any one of those ideas is new.

The ESSAF Architecture

ESSAF separates analytical work from the services that authorize and execute protected actions. The following are logical responsibilities, not a requirement to deploy six separate servers.

The protected execution path is straightforward:

Operator assignment → agent proposal → policy decision → execution gateway → approved resource → recorded outcome.

The control plane and audit service supervise this path. Agents must not have alternative routes to the same protected resources.

Task and Operator Interface

The interface should show the active assignment, approved information, connected capabilities, pending decisions, remaining execution budget, and stop status.

Three distinctions must remain visible: what the agent observed, what it inferred, and what actually happened. A proposed containment action must never appear as completed containment. A generated finding must not appear as verified merely because it contains a source reference.

Governance Control Plane

The control plane evaluates protected operations against an authenticated, versioned policy for the assignment. It should maintain the active authorization, approved identities, per-action permissions, approval records, and revocation state.

Scope, identity, expiry, allowed tools, destinations, and required approvals should be evaluated through deterministic rules. Judgments such as whether ambiguous evidence justifies an operational intervention may still require a person. A model-generated assessment must not convert that uncertainty into permission.

Agent Orchestration

The initial runtime should favor explicit workflow stages: review the assignment, retrieve approved evidence, analyze, check findings, prepare a handoff, and stop. The model can reason within a stage without controlling every transition.

Each delegated task should receive only the context and authority it needs. Runtime limits should bound elapsed time, tool calls, retries, data volume, and resource use. Workflow state belongs in durable storage rather than only in conversation history.

Model and Skills Runtime

Models and skills are replaceable analytical components. Neither may issue credentials, change policy, approve its own actions, or rewrite protected audit history.

Operational context should be retrieved from approved sources with document identity, version, handling restrictions, and source location preserved. Working memory should remain separated by assignment and access boundary. A generated summary must retain its status as an interpretation rather than becoming authoritative evidence through repeated retrieval.

Secure Execution Gateway

The gateway receives structured requests identifying the assignment, actor, tool, target, arguments, evidence references, and intended operation. It validates the request, obtains the policy decision, checks any approval, and invokes an isolated adapter.

Credentials should remain with the broker or adapter, not inside prompts or agent-readable files. Filesystem permissions, process isolation, and network restrictions must prevent direct access around the gateway. Downstream services should independently enforce their own permissions. OWASP's excessive-agency guidance supports this emphasis on narrow capabilities and authorization outside the model. [5]

Evidence and Integration Layer

Adapters should expose narrow operations rather than generic shells or unrestricted administrative APIs. Availability in the connector inventory does not grant an agent access to the connector.

The Model Context Protocol provides interfaces for tools, resources, and prompts; it does not define ESSAF's operational permissions. MCP-based adapters should pass through the same authorization and audit path as other integrations. [6]

Data access must be enforced before content enters model context. Output destinations, case exports, and data movement require their own controls. A local tool can still disclose information to an unauthorized user or expose data outside the approved assignment.

Rules of Engagement as Executable Policy

ESSAF adapts the eight-field Agent ROE Card into an operating contract for everyday cyber workflows. The objective defines the assigned outcome; the remaining fields define how the agent may pursue it. The human-readable assignment and machine-enforced policy should describe the same boundaries. [1]

Each contract should identify its owner, issuing authority, version, validity period, and handling requirements. An assignment identifier should bind the contract to every workflow and tool request. Missing required fields should prevent consequential access.

The authority model remains action-specific:

These are permission categories, not levels an agent earns through good performance. Escalation is available across them.

Prepare deserves particular care. Saving a draft in a controlled workspace is different from creating a ticket that dispatches responders or starts automation. The actual side effect—not the button label—determines which authority is required.

ESSAF should return four policy outcomes: Allow, Deny, Modify, or Approval required. Modify means narrowing the request and submitting the resulting action to complete validation again. Approval required holds an otherwise eligible action; it does not create an exception to a prohibition.

The permitted action must satisfy the assignment's policy, the actor's authority, the adapter's permitted capabilities, current operating conditions, and any required approval. Delegation may narrow that set. It may not enlarge it.

Human Approval, Stop, and Recovery

A useful approval request should show the action, target, supporting evidence, unresolved conflicts, expected operational effect, alternatives, reversibility, and the consequences of acting or waiting.

Approval should be bound to the exact request, assignment and policy versions, approver identity, and expiration. Changing the target, parameters, relevant evidence, or policy should invalidate the prior decision. Authorization must be checked again immediately before execution, not only when the request enters a queue.

ESSAF also retains the original ROE stop conditions: an out-of-scope target; missing or stale required evidence; material evidence conflict; instructions embedded in retrieved content; unexpected tool or schema changes; requests for additional privilege; missing or expired approval; inability to reverse safely; and unavailable policy or audit services. Their applicability must be explicit in each workflow profile. [1]

A real stop must block new work, suspend or cancel queued work, examine in-progress operations, preserve evidence, and notify the responsible person. Temporary credentials should be revoked where appropriate. Audit and operator-review services should remain available even when the agent is stopped.

Stopping an agent is not the same as stopping the network or physical process it is helping defend. An operation that cannot be safely interrupted needs an explicit recovery procedure, not an indiscriminate termination signal.

A timeout must not be treated as proof that an action failed. Before retrying a consequential operation, the framework should check whether it already took effect. Where supported, unique operation identifiers should prevent duplicate execution. Unknown outcomes require reconciliation or human review.

Restart is a separate decision. The responsible people must resolve the cause, verify the controls, and authorize a bounded resumption. Restoring a checkpoint must not restore expired approval or revoked authority.

Secure Skills and Capability Governance

A skill packages reusable instructions and supporting material for a class of work. The Agent Skills specification defines a SKILL.md file with metadata and instructions, with optional scripts, references, and assets. It supports progressive disclosure: load a description for discovery, detailed instructions when selected, and additional resources when needed. [7]

ESSAF should support this format while separating instructional content from security policy.

A hunt skill might explain how to compare authentication patterns, identify missing context, and prepare a finding. A separate ESSAF manifest should declare the skill version, approved dependencies, input and output schemas, requested capabilities, resource limits, and evaluation evidence.

That manifest is a proposed ESSAF extension, not a claim that the base Agent Skills format supplies authorization, signing, or a sandbox.

A governed registry should verify the entire package against an approved signing identity and known release digest. Executable resources should run only through controlled adapters or restricted execution environments. A signature establishes package integrity and the identity of a signer under the configured trust model; it does not establish that the code is harmless or the task is authorized.

Skill selection should expose only capabilities permitted for the assignment. Changes to instructions, scripts, tool descriptions, or dependencies should trigger review and relevant regression tests. Dynamic downloads or self-modifying skills should not be part of the initial controlled baseline.

A skill teaches an agent how to do a task. It does not authorize the agent to do it.

Self-Contained and Model-Agnostic Operation

ESSAF should support self-contained operation when connectivity, data sensitivity, or resilience requirements call for it. In that deployment profile, core inference, identity verification, policy evaluation, retrieval, approvals, storage, and auditing must remain available within the authorized deployment boundary.

Self-contained does not mean that every component lacks a network connection. A deployment may use an approved local network to reach authorized data sources. Disconnected operation means that core functions do not require an external cloud service, public package registry, internet identity provider, or hosted telemetry backend. Connected environments may use approved integrations, but connectivity must not expand an agent's permissions or bypass the execution gateway.

Local inference projects such as llama.cpp and vLLM are candidate components. Their suitability depends on the selected models, hardware, deployment configuration, licensing, and security evaluation. [8, 9]

Model independence requires more than changing an endpoint. ESSAF should maintain an evaluated profile for each model and runtime combination: artifact identity, context limits, structured-output behavior, tool-call handling, hardware needs, and approved workflows. Quantization, chat templates, and runtime changes should be included in that configuration record.

A replacement model should pass the affected evaluations before use. Fallback must select an already approved profile or defer the task; it must not silently send data outside the deployment boundary.

Installation and updates should use reviewed release bundles containing software, models, tokenizers, skills, policies, dependency inventories, and verification material, with offline delivery supported for disconnected environments. Update installation should verify provenance, compatibility, and rollback arrangements without enabling new destinations or permissions.

Identity needs an explicit operating model for each deployment profile. Credentials should have bounded validity and documented revocation and renewal procedures, with local enforcement available for disconnected operation. Clock uncertainty or expired authorization should restrict consequential execution rather than extend it indefinitely.

When AI services are unavailable, approved search, evidence review, and manual case handling should remain usable where feasible. Operational data should not become inaccessible because a model cannot load.

Applying ESSAF to Operational Work

The same control model should support alert triage, incident investigation, threat hunting, vulnerability analysis, and security engineering. Each workflow starts with an authorized objective, approved sources, permitted actions, accountable owners, and completion criteria—not with unrestricted access to every connected tool.

In analytical workflows, an agent may correlate approved records, identify missing context, and prepare source-grounded findings. It should distinguish an observation from a hypothesis and a recommendation from an action. Permission to review evidence does not imply permission to collect more data, scan additional assets, change configurations, or initiate a response.

Where operational changes are permitted, the authorization should name the allowed action, target, prerequisites, approval requirements, and recovery procedure. Controls should reflect the consequences of that action. Work involving physical processes also needs to account for distinct reliability and safety requirements. [10]

Retrieved records, runbooks, tickets, and tool responses are evidence or task material, not sources of new authority. An instruction embedded in that material must not widen access. The applicable stop rule should pause or isolate affected work, preserve the record, and bring the issue to the responsible person; external controls must reject unauthorized actions even if the model misses the instruction attempt.

Resumption should follow a documented review: resolve the cause, reconstruct trusted task context, verify the controls, and authorize a bounded restart. Any expansion of access requires a separate authorization decision rather than an inference that the original task is important enough to justify it.

A handoff should record observations, source references, uncertainty, unresolved questions, and recommended next steps. Authority held by the person receiving the handoff does not automatically transfer to the agent.

The intended outcome is consistent across roles and environments: useful operational support, a reviewable result, and no silent expansion of scope.

Auditing, Evidence, and Reconstruction

ESSAF should maintain an evidence record outside the agent's control. Each consequential step should connect the assignment and policy versions, actor identity, relevant model and skill configuration, source references, tool request, authorization decision, approval, and observed result.

Requested, approved, dispatched, completed, failed, and unknown outcomes must remain distinct. An agent's statement that it performed an action is not a substitute for execution evidence.

Source records should retain their original identifiers, timestamps, provenance, and integrity checks. Findings should distinguish observation from inference and identify evidence that weakens the proposed explanation. A hash can establish that a record has not changed relative to a trusted reference; it cannot prove that the original observation was true.

The proposed audit design should combine append-only permissions, protected signing keys, chained records or signed checkpoints, and separately retained checkpoints where feasible. Tamper evidence depends on those protections. A single local log is not immutable merely because its entries contain hashes.

Logs, prompts, retrieved context, and model outputs may themselves contain sensitive information. Retention, access, redaction, and export must follow applicable organizational policies and the assignment's data-handling rules. Raw credentials should not enter the audit record.

The goal is reconstruction of the observable workflow, not collection of hidden chain-of-thought. Reviewing recorded actions and evidence is also different from rerunning a model and expecting identical text.

Security Guidance and Operational Assurance

OWASP's Excessive Agency guidance addresses excessive functionality, permissions, and autonomy. Its Agentic Applications Top 10 provides a broader risk reference for agentic workflows. These sources should inform ESSAF's threat model and tests rather than serve as labels attached after implementation. [5, 11]

The OWASP Agent Control Standard describes runtime control hooks and portable policy enforcement interfaces. ESSAF should evaluate compatibility with its specification while retaining independent enforcement at protected resources. The four policy outcomes in this paper come from the Agent ROE model; they are not presented as ACS's defined dispositions. [12]

NIST AI RMF 1.0 and its Generative AI Profile provide risk-management guidance. System authorization is a separate responsibility addressed through applicable organizational processes; citing AI guidance does not confer approval to deploy a system. [13–15]

ESSAF should produce evidence useful to that review: architecture and data flows, access rules, configuration records, dependency inventories, test results, incident procedures, and named control owners. No architecture diagram or passing evaluation establishes universal safety or replaces an organization's deployment approval.

Minimum Release Gate

The initial implementation should prove one bounded workflow before adding broader autonomy: approved evidence review, source-grounded findings, controlled local drafting, and a verifiable stop and restart. Live integrations and consequential actions should be considered only after their own authority and safety requirements are defined.

The release gate preserves the original eight checks. [1]

Tests should cover both useful work and boundary failures: injected instructions, unauthorized cross-assignment retrieval, changed tool schemas, stale approvals, duplicate requests, audit failure, resource exhaustion, and attempts to bypass the gateway. Testing of disconnected deployments should verify the absence of required external dependencies, not merely that a demonstration worked after disconnecting a cable.

Evaluation should measure evidence accuracy, unsupported conclusions, analyst correction effort, latency, resource use, and policy violations. Serious failures should become permanent test cases. Changes to models, prompts, skills, tools, identities, policies, or data sources should trigger relevant reassessment. This continues the Evening Star approach of evaluating the complete task loop rather than only the final response. [16, 17]

Closing

ESSAF is intended to make capable agents usable where authority, evidence, and operational boundaries matter as much as analytical performance.

The framework does not need to outperform every existing project at orchestration, inference, or retrieval. It needs to integrate those capabilities without allowing them to override the approved scope.

For blue teams and cyber practitioners, that means using AI to investigate, analyze, prepare, and act only within explicitly granted authority. Across roles, organizations, and deployment environments, the same principle holds: define the assignment, enforce its limits, record the result, and make stopping real.

Capability is not authority. ESSAF is the proposed architecture for keeping that distinction enforceable.

References

Source review: October 15, 2026. Framework documentation may change. The architecture, component selections, and ESSAF-specific controls in this paper are proposals unless explicitly attributed to an external source.

1. Andrew Scott. Rules of Engagement for AI Agents: How to define safe authority for agents operating in cyber workflows. Evening Star AI, September 2026. Foundational publication for the operating-contract model developed here.
2. LangChain. LangGraph overview.
3. Pydantic. Pydantic AI overview.
4. CrewAI. Introduction.
5. OWASP GenAI Security Project. LLM06:2025 Excessive Agency.
6. Model Context Protocol. Architecture overview.
7. Agent Skills. Specification.
8. ggml-org. llama.cpp: LLM inference in C/C++.
9. vLLM Project. vLLM: Inference and serving engine.
10. NIST. SP 800-82 Revision 3: Guide to Operational Technology (OT) Security.
11. OWASP GenAI Security Project. OWASP Top 10 for Agentic Applications for 2026.
12. OWASP GenAI Security Project. Agent Control Standard.
13. NIST. AI Risk Management Framework.
14. NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1, July 2024.
15. NIST. SP 800-37 Revision 2: Risk Management Framework for Information Systems and Organizations.
16. Andrew Scott. Practical Evals for Agentic Systems. Evening Star AI.
17. Andrew Scott. Red Teaming Agentic AI Systems. Evening Star AI.