ASPEN

The analyst environment for a preemptive platform

ASPEN is not a retrofitted log aggregator. It is built to ingest and correlate deception-native telemetry alongside conventional log sources, enrich every event with CATIS predictive context before an analyst ever sees it, and run detection logic retroactively across the full historical index.

Deception signals from ACD, predictive intelligence from CATIS, DNS events from ShenDNS, and endpoint telemetry converge into a single correlated, enriched, searchable dataset for SOC analysts, threat hunters, and forensic investigators. ASPEN is licensed as a standalone product and integrates natively with the full AST platform as well as third-party security infrastructure.

Two problems, one environment

Volume without intelligence. Conventional SIEM platforms collect vast quantities of log data but lack the contextual enrichment needed to separate meaningful signal from noise. Alert fatigue is a systemic problem, consuming analyst capacity without producing actionable outcomes.

Deception signals without a home. ACD sensors generate high-confidence attack telemetry — zero false positives by architecture, because every interaction with our decoy is adversarial by definition. That value is only fully realised when those signals are correlated with DNS events, endpoint activity, lateral movement indicators, and historical behavioural baselines.

ASPEN solves both at once, giving the analyst an environment in which the complete attack picture — from the first reconnaissance probe to lateral movement — is visible within a single investigation session.

Engineered specifications

How ASPEN works

ASPEN operates as a big-data indexed analytics platform with a high-throughput ingestion pipeline, real-time and retrospective correlation engines, an AI-assisted analyst interface, and a distributed multi-instance architecture.

Ingestion and enrichment

ASPEN receives telemetry from the full AST sensor network and from any standard log source — syslog, CEF, JSON, and custom formats. Every event passes through an enrichment pipeline that injects CATIS context, anomaly flags from deception sensors, and behavioural risk scores, so events arrive at the investigation interface already reduced to analyst-ready, pre-contextualised alerts.

Real-time correlation

Correlation rules execute over live event streams with sub-10ms latency, enabling detection of attack patterns as they develop and disruption of a forming kill chain, sustained at 50,000 EPS under large enterprise and government data volumes.

Post-write correlation

Beyond real-time alerting, ASPEN executes detection logic retroactively over historically indexed data. Threat hunters can apply new detection rules to past events, surface activity that predates rule creation, and test hypotheses across the complete historical timeline. This is decisive for APT investigation and campaign attribution, where attacker presence may precede detection by weeks or months, and it directly reduces attacker dwell time.

Behavioural consistency analysis

ASPEN’s detection architecture moves beyond signature- and rule-based detection to evaluate behavioural patterns across multiple data dimensions over time, surfacing novel techniques that carry no known signature but are inconsistent with the organisation’s established baseline.

AI-assisted analyst environment

LLM interactive console

Analysts search, investigate, and reason about security events in natural language rather than query syntax alone, requesting contextual summaries of alert clusters and navigating complex multi-event attack chains conversationally. The operating model is human-on-the-loop: the analyst monitors and decides, without being required to participate in every detection or blocking action.

LLM automated reporting

ASPEN generates structured, human-readable summaries of security events, incident timelines, campaign assessments, and threat-hunting findings without manual authoring. This covers periodic operational reports, incident reports with MITRE ATT&CK mapping, and non-technical executive summaries — KPIs, trends, and Mean Time To Neutralize — on demand or on schedule.

Multi-instance architecture

ASPEN supports deployment as multiple interconnected instances with configurable selective data exchange between nodes, letting organisations align their analytics architecture with operational, geographic, and classification requirements.

Deployment and integration

Deployment models

• On-premises (customer-controlled) — the primary model for enterprise and government environments
• Hybrid — on-premises ingestion and correlation with optional managed components
• SaaS — for customers without on-premises infrastructure requirements
• Air-gapped — fully isolated deployment for classified and high-security environments

Third-party integration

• Ingestion from any standard log source via syslog, CEF, JSON, or custom connectors
• Output to external SOAR platforms, ticketing systems, and reporting infrastructure via standard APIs
• STIX/TAXII export for threat intelligence exchange between platforms

Telemetry sources within the AST platform

ASPEN vs. conventional SIEM

Securing and governing enterprise AI

Organisations are running AI in production before they have any record of what it does. Prompts leave the perimeter carrying source code and personal data, agents call internal APIs with delegated credentials, and generated content is published with no marking trail behind it. ASPEN treats that traffic as a first-class telemetry source: prompts, model responses, and agent tool calls are captured inline, correlated with the rest of the security estate, and indexed so the record outlives the session.

The section above — AI-assisted analyst environment — is AI powering ASPEN for the analyst. This section is the inverse: ASPEN monitoring your organisation’s own AI.

AI prompt and response DLP

Every outbound prompt and inbound response is scanned in real time, before it reaches an external model, for secrets, credentials, personal data, source code, and intellectual property. Policy decides per match: block the call, redact the fragment, or allow it and alert. Matches involving personal data are raised as candidate GDPR events, carrying the evidence a breach assessment needs.

• Inline enforcement at the gateway, so a blocked prompt never reaches the provider
• Detection classes cover credentials and API keys, personal data, source code and build artefacts, and customer-defined intellectual property patterns
• Every decision recorded with the policy matched and the action taken

AI transparency and disclosure assurance

Article 50(1) of the EU AI Act requires a person to be told they are interacting with an AI system at or before the start of the interaction, and Article 50(2) and 50(4) require generated content to carry machine-readable marking. A setting enabled in a console is not evidence that either happened. ASPEN verifies continuously that the disclosure is actually served at session start and that marking is present on generated output before publication, and keeps a timestamped audit trail of both checks.

• Covers first-party chatbots and white-labelled third-party assistants embedded in your own properties, where the code is a vendor’s but the obligation is yours
• A disclosure silently removed by a deployment or a theme change is raised as a compliance event, not a cosmetic one
• Marking is checked before publication, while a failure is still cheap to correct

Prompt injection and jailbreak detection

Detection covers direct injection in user input and indirect injection carried in retrieved content — a poisoned document, a fetched web page, an email body an agent was asked to summarise. Jailbreak patterns and known bypass families are matched on the response as well as the prompt, because a successful attempt is often only visible in what the model produced. Detections are mapped to MITRE ATLAS, so AI-specific activity is reported in the same frame as the rest of the estate.

AI incident detection and regulatory reporting

AI-linked signals — a compromised model account, an agent exfiltrating data, an action taken outside its authorised scope — are correlated into qualified incidents rather than left as isolated alerts. For essential and important entities under NIS2, each qualified incident is tracked against the 24-hour early warning and 72-hour report obligations from the moment it qualifies. Prompts, responses, and agent actions are reconstructable in full for the investigation and for the report itself.

AI agent action auditing

Every tool call and API invocation an agent makes is audited against the scope it was authorised for, surfacing privilege creep, unsanctioned plugin and connector use, and actions that fall outside the approved boundary. The retained call sequence is what human-oversight obligations under Article 26 are demonstrated with — evidence that a person could see what the system did and had the means to intervene.

Record-keeping for high-risk AI systems

Where an AI system is high-risk under the EU AI Act, Article 12 requires it to technically allow automatic recording of events over the system’s lifetime, and Articles 19(1) and 26(6) require those logs to be retained for at least six months by provider and deployer respectively. ASPEN’s role is the one it already plays for the rest of the estate: automatic capture, enrichment on ingest, and an indexed history that stays queryable, with retroactive correlation across events that predate a detection rule. These duties arrive with the deferred high-risk timeline — 2 December 2027 for standalone Annex III systems — not with the Article 50 transparency deadline; the distinction, and the full requirement set, are on our EU AI Act page.

ASPEN produces the monitoring, logging, and evidence infrastructure that a compliance position depends on. It does not, by itself, make an organisation compliant, and AST is not a law firm — confirm with counsel which obligations apply to your systems and to your role as provider or deployer.

AI Agent Integrity Monitoring

The section above produces the evidence a regulator asks for. This one enforces a security boundary. The same telemetry, with a different question asked of it.

An agent that has been manipulated by the content it processed does not look like an intrusion. Its credentials are valid, its identity is authorised, and it is doing what it believes it was asked to do. Controls that look for compromise find nothing, because there is no compromise to find — which is why ASPEN monitors the boundary an agent is supposed to operate inside rather than the content it consumed.

Enterprise agents read documents, RAG corpora, repositories, tickets, web pages and API responses. Untrusted content in any of those can influence how an agent behaves. ASPEN already detects indirect prompt injection carried in retrieved content and maps AI-specific activity to MITRE ATLAS; agent integrity monitoring adds the behavioural layer above that, across four observable areas.

Retrieval integrity

Detects when an agent accesses information outside its expected retrieval scope — a corpus, repository, or document class it has no business reading for the task it was given. A retrieval-boundary violation is often the earliest observable sign that an agent is pursuing something other than its assigned objective.

Tool integrity

Detects unexpected tool, API or MCP invocation. Every call is already audited against the scope the agent was authorised for; integrity monitoring adds the pattern view — tools invoked in an order, combination, or frequency the agent’s role does not account for.

Behavioural integrity

Detects material change in an agent’s behaviour after it processes external or untrusted content. This is the area conventional controls cover least well, because the change is legitimate in form and only anomalous in relation to how that agent normally behaves. ASPEN’s behavioural consistency analysis is the same mechanism already applied to the rest of the estate, with the agent as its subject.

Action integrity

Detects attempted actions outside the agent’s approved role, policy or workflow — the point at which influence becomes consequence. Because ASPEN holds the full call sequence, an action can be traced back through the tool calls and retrievals that preceded it.

Taken together these describe one boundary with four edges: a scope an agent should read from, a set of tools it should call, a baseline it should behave within, and a role it should act inside. Manipulation surfaces as a departure from one of them, whatever produced it.

Controlled canary content and behavioural telemetry can be used to validate that those boundaries hold in your environment rather than holding in principle. The content of those controlled objects is not disclosed. The wider capability, including agent-aware deception on the attack side, is set out on autonomous AI agent security.

Where ASPEN sits in the platform

ASPEN is the analyst environment and system of record of the AST platform. Every sensor, prevention element, and intelligence layer sends telemetry to ASPEN, making it the basis for security operations, forensic investigation, compliance reporting, and threat hunting across the deployment.

CATIS and ASPEN are complementary and architecturally separated: CATIS transforms deception telemetry into preemptive intelligence for the autonomous prevention loop, while ASPEN converts that same telemetry, combined with the organisation’s full security data, into investigative clarity for the human analyst. Together with ACD, NanoFirewall, and ShenDNS, ASPEN completes the end-to-end architecture — from an attacker’s first contact on the deception surface, through intelligence production and autonomous prevention, to full forensic visibility.