The starting point for this project was simple: a SOC rarely lacks alerts. What it lacks is the time, context, and consistency required to turn alerts into decisions.

WAF sees request characteristics, RASP sees runtime call stacks, HIPS sees host behavior, NDR sees network connections, and SIEM turns only part of that material into an event. The data is plentiful, but fields, timelines, evidence strength, and response language differ. During a peak, the work that consumes an analyst’s attention is often not discovering an entirely new attack. It is repeatedly understanding vendor logs, filling evidence gaps, finding similar incidents, writing a verdict, listing response steps, and checking which actions require approval.

That is the part of the workflow a Defensive AI Agent is meant to improve. It is not a replacement for security controls, and it is not a chat window bolted onto a log system. It is closer to a decision gateway between detection products and response processes: normalize evidence, let a model summarize, correlate, and generate hypotheses, then use deterministic code, human review, and approval systems to constrain how far the model can move the case forward.

AI is moving from answering questions to participating in workflows

Over the past two years, the use of large models in security has shifted. Early requests were usually to explain a log line, generate a query, or summarize a report. The more valuable direction now is to let a model work continuously inside governed tools and an explicit state machine: read a Case, propose an investigation plan, collect more evidence, revise a hypothesis, and produce an executable-but-not-yet-executed response plan.

That shift creates new engineering requirements. Once a model becomes a participant in a workflow rather than an answer engine, accuracy is only one question. We also need to know what it saw, what it called, whether it exceeded its authority, where an alert went after a failure, and whether one bad experience can contaminate later decisions.

The initial draft of the NIST Cyber AI Profile describes the intersection of AI and cybersecurity in three directions: securing AI systems, using AI to improve defense, and defending against AI-enabled attacks. A Defensive AI Agent is primarily in the second category, but controls from the first category must enter the design as well. We cannot use AI to defend a system while turning the AI itself into a new high-privilege entry point.

OWASP’s work on agentic AI is even more direct: tool misuse, identity and permission abuse, goal hijacking, and memory or context poisoning become much larger risks once an Agent can act. Excessive Agency traces the root causes to too many functions, too much permission, and too much autonomy. Our design deliberately moves in the opposite direction: narrow tools, read-only permissions, and independent approval for high-impact actions.

The hard part is not calling a model API

A first prototype is easy: receive JSON, assemble a prompt, call a model, and render the answer. Once integration starts, the difficult work quickly moves from the model call to system engineering.

This led to four principles that have not been compromised: facts and model opinions are stored separately; probabilistic analysis and deterministic gates are implemented separately; investigation and execution have separate authorization; and a model outage may delay processing but must not silently change the analysis policy.

The current architecture

The online environment is currently a single-host deployment. Caddy provides the HTTPS boundary. Gateway and Vector run in Docker. Vector receives security-product Syslog; Gateway owns the HTTP API, analysis orchestration, and workbench. SQLite stores facts, state, and audit records. The model is called through an enterprise LLM Gateway and is never exposed directly at the public edge.

This shape is suitable for integration, demonstrations, and a small PoC. It shows the complete control path, but it is not a highly available production cluster. That boundary matters and is addressed separately below.

1. Ingestion first has to be reliable enough to retain the event

The system accepts both HTTP JSON and Syslog. WAF, HIPS, NDR, RASP, and SIEM each use an independent product route. In the single-host deployment, Vector listens on ports 15140 through 15144; TCP is preferred for formal integrations. RASP messages with long call stacks use a 2 MiB frame limit so the smaller default Collector buffer cannot silently truncate them.

Vendor logs do not need to be converted into the internal format before they arrive. A Mapping Profile handles field paths, type conversion, and product semantics. It can infer candidate mappings from redacted samples and run them in dry-run mode. Content fingerprints recognize common product formats. Data with an unknown source that does not satisfy the alert contract is rejected instead of being sent vaguely into a model.

After mapping, an alert is written to durable_alert_inbox; the endpoint returns 202 only after the write succeeds. If the remote model is temporarily unreachable, the record enters deferred and is released after recovery. Authentication failures, invalid endpoints, and response-contract failures are configuration problems that require repair and enter the DLQ. When queue count, byte, or disk-retention watermarks are reached, the endpoint returns 429, pushing pressure back to Vector’s disk buffer.

One small constraint is especially important: alert_id is the immutable idempotency key for an alert instance. The same ID with the same content can be safely retried. The same ID with a different time, field, or evidence returns 409 alert_id_conflict. The system would rather make an upstream identity conflict explicit than overwrite a fact already inside the audit chain.

2. The model sees an evidence projection, not the raw data warehouse

Each alert is stored in two main forms. RawAlert preserves the original fact. NormalizedEvent stores the entities, evidence references, sensitive-data labels, and normalized semantics used for analysis. RASP cases also record original-log byte count, Syslog message byte count, two SHA-256 values, the number of items[], and the state of hook_data and stacktrace.

The most useful part of this design is not merely redaction. It preserves field state:

• present means the upstream source supplied content;
• empty means the field exists but is empty under the protocol semantics;
• missing means the source did not supply the field;
• a summary value means the original remains available for local review but is not sent in full to the model.

If a value is simply replaced with asterisks, a model can mistake “redacted” for “no evidence.” Explicit state lets it distinguish a GET request that naturally has no body, a collection gap upstream, and a value withheld by the gateway for data minimization.

3. Five product Agents share a framework, not a verdict template

The gateway selects a WAF, HIPS, NDR, RASP, or SIEM Agent by product. They share a structured output contract but have different priorities:

• WAF focuses on request features, rule matches, and false-positive conditions;
• RASP focuses on whether input reached a dangerous call site, the stack, hook data, and the RASP action;
• HIPS focuses on processes, files, accounts, and host behavior;
• NDR focuses on connections, direction, frequency, and network timelines;
• SIEM fuses Cases from multiple sources and identifies evidence gaps.

Model output includes classification, confidence, evidence, missing evidence, reasoning, and staged response recommendations. At the Case layer, alerts are grouped by asset, rule, and time window so one activity does not produce seven approval packages. Cross-product correlation uses restricted time windows and entity matching as an investigation lead only; proximity in time does not automatically become the same attack chain.

4. The Validator does not trust the model, including a model that checked itself

After an Agent returns, an independent deterministic Validator checks the result. It does not call an LLM. It verifies:

• classification and confidence against the structured contract;
• immutable evidence references for high-risk conclusions;
• consistency between returned evidence and normalized facts;
• sensitive-field leakage or suspected credentials;
• prompt-injection text in external logs;
• whether recommended actions are correctly marked read-only or approval-required;
• whether the active Skill explicitly forbids production execution.

The final states are passed, review, and blocked. passed means the output cleared evidence and permission gates for this analysis. It does not mean the alert has been proven malicious, and it certainly does not mean the model is always correct. That distinction must remain clear in the workbench; a green status is easy to misread as a security conclusion.

For prompt injection, the original Validator result is retained. Only when the external log is the sole issue, while every other deterministic check passes, may an analyst document the review basis and send the result to approval. Automatic memory insertion remains suppressed. This prevents a line such as “ignore previous instructions” from discarding an entire security event while also preventing it from poisoning future workflow context.

5. Memory is a governed object, not a longer prompt

The system separates Case short-term memory, product long-term memory, asset profiles, organizational knowledge, and read-only evidence references. A new false-positive experience does not become active because a model says “ignore this next time.” It needs a traceable source, scope, human approval, expiry, and sensitive-data checks. Promotion, rejection, quarantine, and restoration are written to a separate event stream.

Memory matching combines structured fields, semantic similarity, and retrieval keys. It also has veto conditions: when the current event matches a dangerous runtime call chain, a historical false-positive memory cannot automatically lower the malicious signal. Online configuration currently keeps automatic application and model injection disabled, retaining candidate evaluation and governance screens only. Without a stable Golden Set, remembering more is not necessarily safer than making a decision more slowly.

6. The Response Agent investigates; it does not own production execution

The Response Agent expands a one-shot recommendation into a pausable, resumable, auditable investigation session. The model may choose the next read-only tool from a fixed allowlist. The controller locks the Case scope, normalizes arguments, limits rounds and tool budget, and persists steps, observations, result hashes, and evidence references.

It can read the Case snapshot, evidence inventory, raw-alert chunks, timeline, governed memory, and response state. It can also inspect web requests, runtime state, endpoint processes, file integrity, network boundaries, authentication, persistence, cloud, and container evidence. For selected raw evidence, the controller requires continuous reading from byte offset zero through the end and recomputes the full hash. Skips, gaps, source changes, and digest mismatches cannot pass the report gate.

The model cannot submit SQL, table names, database paths, Shell, arbitrary URLs, or device credentials. It can generate a candidate plan with success and rollback conditions, but destructive actions are always escalated as approve_required. Finishing an investigation does not mean execution has started.

Response Automation, Playbooks, execution verification, and rollback state machines are implemented in code. The online policy remains disabled and no production Connector is configured. The system can therefore demonstrate a complete governed path without allowing a page approval to block an address or isolate a host. That is a deliberate trial-stage boundary, not a hidden capability gap.

How one RASP Case is handled

One current RASP Case involving a memory shell illustrates why this boundary matters. The request is a GET to a test application’s memory-shell endpoint. RASP rule cloudrasp_memShell_105 matches. The call stack passes through Spring MVC’s MappingRegistry.register and registerMapping, then reaches HandlerMethodShell.addShell in test code. From a runtime-reachability perspective, this is stronger than a WAF URL match: it shows that the registration logic reached a monitored call chain.

The evidence also has limits. The RASP action is log, not block. hook_data is empty. There is no host-side evidence of class loading, persistence, or follow-on execution. The path and class name look like a lab, while the system has no authorization record for this test.

The Agent returns suspicious with confidence 0.5 and asks for human review. It recommends checking authorization, Tomcat and application logs, and dynamic mappings in the JVM before deciding on a temporary allowlist or source isolation. Observation and collection remain read-only. Allowlisting, blocking, and clearing a memory shell are marked approve_required. Every deterministic Validator check passes.

The result is not dramatic, but it is more useful than “memory-shell attack successful.” The system confirms that a dangerous call chain was reached while honestly retaining the evidence gap between a rule match and a compromised host. Security analysis is harmed less by a quiet answer than by hidden uncertainty.

Runtime snapshot on August 7, 2026

The following values came from the online health endpoint and Case database while this article was written. They describe the current integration dataset, not a detection rate or a count of independent attacks.

The runtime was Ubuntu 24.04 with Gateway database schema v22. Caddy, Gateway, Vector, the durable queue, and the Response Agent Worker all passed health checks. Model calls used the configured enterprise gateway. “Healthy” here describes component and queue state; it does not claim that future capacity or high availability is complete.

The design choices worth keeping

The reusable value of this work is not a particular prompt, but a set of engineering choices.

First, evidence continuity comes before context length. Complete originals, normalized evidence, model runs, validation, approval, and audit records are separate objects joined by IDs. Model context may be truncated; fact identity may not be ambiguous.

Second, failures enter the state machine explicitly. Model unavailability, permanent configuration errors, queue capacity, and human review are different problems. They belong in deferred, DLQ, backpressure, and review states rather than one generic “processing failed.”

Third, probabilistic capability stays inside a deterministic control plane. The model handles semantic summarization, correlation hypotheses, and report language. Code owns evidence consistency, sensitive output, permission, approval, and execution boundaries.

Fourth, memory must be reversible. Every experience has a source, scope, trust level, approver, and expiry, and high-risk evidence can veto a bad memory. It is slower than simple vector retrieval, but closer to how security operations actually govern allowlists and exceptions.

Fifth, an investigation Agent is not an autonomous response Agent. Read-only tools can support deep investigation. It is safer to establish Case scope, original evidence, and report quality before discussing open execution permissions.

These choices align with the NIST AI RMF Generative AI Profile’s focus on measurement, governance, and lifecycle risk management. The response workflow also follows the spirit of NIST SP 800-61 Rev. 3, which brings incident response into CSF 2.0 risk-management activities. Standards do not design a product for us, but they give us a useful test: does the system merely display model capability, or can it explain how that capability is governed?

Production work that is still outstanding

The current system is fit for a controlled trial. A complete feature path is not a reason to skip infrastructure work.

The data plane is still one Gateway, one Vector, and SQLite. Production needs Case and governance state in PostgreSQL, an alert stream in Kafka, Redpanda, or RabbitMQ, large raw evidence in object storage, and separate ingestion and analysis workers that can scale independently.

Collectors also need dual instances, source-network allowlists, an mTLS relay, sender acknowledgements, and failure drills. RASP already uses TCP as its formal path; the compatibility UDP entry should eventually be removed. Identity needs enterprise SSO/IAM, secret management, certificate lifecycle, and separation-of-duty auditing instead of long-lived standalone tokens.

Model quality cannot be proven by running a few real Cases. The next stage needs a private Golden Set built from redacted field samples, covering true attacks, false positives, insufficient evidence, prompt injection, and cross-product correlation. It should continuously measure accuracy, evidence-reference quality, LLM P95, oldest wait time, failure types, and model or rule-version drift.

Execution is the final step: connect approval results to tickets and SOAR while retaining two-person approval, least privilege, TTLs, success conditions, execution write-back, and rollback. Until those controls can be exercised and audited, automatic response is additional risk rather than capability.

Conclusion

After this phase, I would describe the Defensive AI Agent more conservatively. AI is not valuable because it presses the final button for an analyst. It is valuable because it organizes scattered evidence into a reviewable Case, writes down uncertainty, turns repetitive investigation into a stateful recoverable workflow, and brings every recommendation to the approver with its source and boundary intact.

When a system can answer “Why this judgment? What is missing? Who approved it? Where did it fail? Can it be rolled back?”, the model has truly entered security operations. Until then, however fluent the answer, it is still another signal that needs to be investigated.

References

• NIST IR 8596 (Initial Preliminary Draft): Cybersecurity Framework Profile for Artificial Intelligence
• NIST AI 600-1: Artificial Intelligence Risk Management Framework, Generative Artificial Intelligence Profile
• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• OWASP Top 10 for Agentic Applications for 2026
• OWASP LLM06:2025 Excessive Agency