Agentic Defense Solutions · ARIA · Architecture reference

How ARIA is built.

The overview makes the case: what changes at runtime, the record it produces, and the five human-authority modes. This page is what is behind that case: how agents are composed and scoped, what ships and how it deploys, and the full capability inventory an architect checks against a requirement.

Request a Briefing Read the ARIA overview

Multi-agent execution

Agents with a scope and an abort condition.

ARIA does not give you a model with a tool belt. An agent is a typed entity with declared tools, declared knowledge sources, a scope it cannot exceed, and criteria under which it stops. Agents collaborate over a shared plan graph, and the graph is an artifact.

Composition

Plan graphs, not prompt chains

Work is decomposed into a plan graph with explicit pre-conditions and abort criteria. Scheduling and parallel execution are governed. Workflow state persists with checkpointing, recovery, and replay, so an interrupted engagement resumes rather than restarts.

Collaboration

Shared context, scoped permissions

Agent-to-agent communication carries shared context and provenance, but permissions stay scoped per agent. One agent obtaining a capability does not grant it to the next one in the chain.

Tools

MCP integration, authorized

Model Context Protocol integration for tool discovery and authorized execution. Discovery does not imply permission — every invocation passes tool authorization, and generated commands are checked against per-agent shape allowlists.

Artifacts

Immutable and bound

Plans, intermediate results, tool invocations, and findings are emitted as immutable versioned artifacts, cryptographically bound to agent identity, model, prompt fingerprint, and the tool call that produced them. A revision creates a new linked record, never an overwrite.

Human authority is configured per workflow and per risk class, using the five modes on the ARIA overview. Authorization and attestation are records in their own right, bound to reviewer identity and scope.

What ships

Backend and frontend, usable independently.

Teams that already have an interface take the backend only. Teams that want a head start take both. Neither choice changes the compliance posture.

ARIA services

Policy engine with rule-based enforcement and priority-based conflict resolution
Deterministic decision processes with model output validation and decision chains
Decision replay to a specific rule, policy, or human approval
Output validation enforcing the advise-don't-decide pattern
Governed multi-agent workflow execution with scheduling and parallel execution
Real-time monitoring, logging, and analytics per workflow step
Redis-backed session storage with high availability
Unified OpenSearch/Elasticsearch abstraction

Security and cryptography

Immutable audit logs with HMAC-SHA256 integrity hashing and chain verification
FIPS 140-2/140-3 validated cryptography with automatic mode detection
Multi-provider KMS (AWS, Azure, HashiCorp) with automated key rotation
CAC/PIV authentication with X.509 certificate validation
JWT authentication with Keycloak integration and RBAC
Encrypted configuration and secret management
Automated compliance operations with configuration drift detection
SIEM integration

Deployment
Authorized cloud · on-premises datacenter · air-gapped or disconnected enclave
Docker and Kubernetes with Helm charts · horizontal scaling
No required outbound dependencies. No outbound telemetry to vendor-controlled infrastructure.
The same stack supports an internet-connected deployment and a fully isolated one.

For architects and technical evaluators The full inventory behind the four runtime guarantees. The case for them, and what a reviewer sees, is on the ARIA overview.

Capability detail.

Control plane for AI reasoning

Policy engine with rule-based enforcement and priority-based conflict resolution
Deterministic decision processes with model output validation and decision chains
Decision replay to a specific rule, policy, or human approval
Output validation enforcing the advise-don't-decide pattern
Configurable human-in-the-loop approval workflows
Governed multi-agent workflow execution with scheduling and parallel execution
Agent-to-agent communication with shared context, scoped permissions, provenance
Persistent workflow state with checkpointing, recovery, and replay
Model Context Protocol (MCP) integration for tool discovery and authorized execution
Real-time monitoring, logging, and analytics per workflow step
Typed agents with explicit tools, knowledge sources, scope, and abort criteria
Shared plan graph for multi-agent collaboration
Tool authorization gating every invocation, with per-agent scope
Classification and releasability gating on every model and tool call

Audit, identity, and cryptography

Immutable audit logs with HMAC-SHA256 integrity hashing and chain verification
FIPS 140-2/140-3 validated cryptography with automatic mode detection
Multi-provider KMS (AWS, Azure, HashiCorp) with automated key rotation
CAC/PIV authentication with X.509 certificate validation
JWT authentication with Keycloak integration and RBAC
Automated compliance operations with configuration drift detection
SIEM integration
Immutable versioned artifacts bound to agent identity, model, prompt fingerprint, and tool call
Tenancy- and classification-scoped retrieval
Encrypted configuration and secret management

Model abstraction

Multi-provider support: commercial APIs, open-weight, and on-premises models
Single abstraction across providers: swap the model without re-architecting
Response caching, usage tracking, and per-model quotas
Circuit-breaker patterns for automatic failover
Per-model cost, token, and latency accounting

Deployment

Authorized cloud environments, on-premises datacenters, and air-gapped or disconnected enclaves
Docker and Kubernetes with Helm charts, horizontal scaling
Redis-backed session storage with high availability
Unified OpenSearch/Elasticsearch abstraction
No required outbound dependencies, and no outbound telemetry to vendor-controlled infrastructure — the same stack supports an internet-connected deployment and a fully isolated one

Where it slots in

Beside an existing LangChain or LangGraph investment, not instead of it
Beside a model already trained in an accredited enclave
Beside a copilot a program has already fielded
Beside the integrator or prime who owns the mission application

What it is not

Not a foundation model, and not a model provider
Not an agent framework competing with orchestration tooling
Not an accreditation: it is the evidence an accreditation needs
Not a replacement for the integrators or mission teams around it

Orchestration frameworks were never meant to close this gap. Their design center is developer velocity; policy, audit, and compliance are explicitly out of scope. That is not a criticism of them: it is the reason a separate layer exists.

Human-in-the-loop is not a checkbox.

Almost every AI vendor claims to support human-in-the-loop. Almost none of them mean the same thing by it. The result is that procurement teams check a box that does not protect them, and reviewers cannot tell whether the human had authority over the decision or merely witnessed it.

Below is the working taxonomy ARIA implements. Five modes, distinct postures, distinct guarantees. A solicitation can specify against these; it cannot specify against the phrase "human-in-the-loop."

Related reference: Policy, approvals, and governed actions

Related reference: Agents, workflows, and MCP integration

Related reference: Models and deployment

Mode	Behavior	Appropriate for	Not appropriate for
AdvisoryDecides: model	AI executes; a human reviews afterward and can flag or annotate.	Low-risk, high-volume work where post-hoc review suffices: first-draft summarisation, suggested classifications, candidate retrievals.	Anything touching a downstream system the institution is accountable for.
GatedDecides: human	AI proposes; a named human must approve before the action executes. Approval is attributed and logged.	Actions with consequence: releasing an artifact, sending a communication, executing a tool that touches a system of record. The mode a mission system should assume by default.	High-volume, low-consequence work, where the approval queue becomes the bottleneck.
DeferredDecides: human	AI executes immediately; review is queued and required within a window. The action is reversible until reviewed and rolls back if it is not.	Time-sensitive operations where waiting defeats the purpose: incident-response containment, defensive cyber blocks, automated triage.	Anything not genuinely time-critical, or not reversible.
ConditionalDecides: both	Approval fires only when a defined condition is met: a risk threshold, classification level, dollar value, counterparty match.	Graduated risk — most agentic SOC work, supply-chain reconciliation, analyst tooling. The condition becomes the policy artifact reviewers examine.	Cases where the threshold cannot be stated precisely enough to defend.
EscalatedDecides: human	AI handles the routine; a named role handles the edge case. Escalation is policy-driven and the role is attributed at the moment of escalation.	Tiered operations — junior analyst on tier one, senior analyst on escalation, watch officer on the highest tier.	Flat organizations with no defined tiering.

An HITL claim is only meaningful if the system can prove the loop closed the way it was supposed to. That requires configurable mode per workflow and per risk class, attribution to a named human at every checkpoint, and a record of the approval that is as durable as the record of the action.

Authorization and Attestation Objects

Design decision

Authorization and attestation are objects,
not interface states.

Most systems treat approval as a button that unblocks a queue. ARIA treats it as a record with its own identity, cryptographically bound to what was approved, who approved it, and what scope the approval covered. That distinction is the whole difference between a workflow and an audit trail.

Authorization

Before an action expands its own scope

Plan steps that change scope, expand a target set, or invoke a privileged tool enter an authorization queue scoped to reviewers bound by CAC/PIV. A reviewer may Approve, Reject with rationale, or Approve with constraints. The record is bound to the plan step, the reviewer identity, and the scope. No such step executes without it.

Attestation

Before an output leaves the system

Findings enter an attestation queue. A reviewer may Accept, Reject with rationale, or Edit and accept. The attestation is bound to the finding, the reviewer, and the artifact version. Nothing is exported, integrated downstream, or cited in a deliverable without one.

What the audit log contains

Caller identity and agent identity
Policy decisions, including which rules were evaluated
Prompts and outputs
Retrieved evidence
Tool arguments and tool results
Model identity and prompt fingerprint
Timestamps, integrity hash, and chain position

What that makes possible

Reconstruction of any finding back to its originating artifacts, plan steps, and authorizations
Immutable records: a revision creates a new linked record bound to the prior version, never an overwrite
Export in the formats accreditors accept
Answering "who authorized this, and what did they see" without a forensic exercise

Reliability and Hallucination Controls

Reliability

Hallucination is an engineering problem,
not a disclaimer.

A model output can sound confident and be wrong. In a mission system that is not an inconvenience, it is the failure mode. ARIA does not solve it by asking the reader to be careful, and it does not claim to make a model correct.

Two different things are worth separating, because vendors routinely conflate them.

What the layer guarantees

An unverified output cannot reach a downstream system on its own
Every output enters a review state scoped to named reviewers
The model, prompt fingerprint, retrieval set, and tool calls behind an output are recorded whether or not anyone looks
A generated command is checked against a per-agent shape allowlist and runs only where it is permitted to

What a workflow can be built to add

Citations from each claim back to a source artifact and character range
Confidence scores calibrated against a held-out adjudicated set, with calibration error reported
A two-stage check separating "is it present" from "is the evidence sufficient"
Staleness surfaced as its own finding type when a retrieval corpus has drifted

The distinction is the honest one. A workflow author decides how rigorous a given analysis is; the layer decides what an unverified answer is allowed to do. The second is what makes the first worth doing, because a careful workflow with no gate underneath it is one deployment away from being bypassed.

Worth saying plainly

None of this makes a model correct

It makes a wrong answer visible, attributable, and unable to act on its own. That is a smaller claim than most of this market makes, and it is the one that survives a review.

Worth saying plainly

The adjudication pattern shows the rigorous end

Typed findings, source-span citations, and calibrated confidence are real and demonstrable, as the output shape of a workflow built that way. See what a workflow can emit.

Integration Responsibilities (The Trade)

The trade

You keep the application.
We carry the review burden.

The work that stalls an agentic program is almost never the application logic. It is the subsystem nobody scoped: the policy gate, the audit record, the identity binding, the evidence an assessor will ask for. ARIA is that subsystem, built once.

You build and own

The application, its interface, and its data model
The domain logic and the workflows that matter to your mission
Your intellectual property, without a license-back
The integrations into your existing systems of record

You inherit, rather than rebuild

Policy enforcement ahead of every model and tool call
The immutable audit log and its export formats
CAC/PIV and RBAC identity binding
Model brokerage across providers behind one abstraction
Compliance operations and configuration drift detection

Detailed Function Specifications

What the control plane does

Six functions, on every call.

Applied to every model invocation and every tool invocation, by construction, not by convention, and not as something the application developer has to remember.

Policy enforcement

Legal, classification, organizational, and contractual rules evaluated before any downstream system sees anything. Declarative, versioned, organizationally owned. Priority-based conflict resolution when rules disagree, and the resolution is itself auditable.

Prompt and output audit

Prompts, outputs, retrieved evidence, tool arguments and tool results recorded against caller and agent identity. Not sampled. Not a debugging trace.

Model brokerage

One abstraction across commercial APIs, open-weight models, and on-premises deployments. Swap the model without re-architecting. Per-model quotas, caching, cost, token and latency accounting, and circuit-breaker failover.

Identity and scope

CAC/PIV with X.509 validation, JWT with Keycloak integration, RBAC. Every agent carries an explicit scope, and an action outside that scope does not silently succeed.

Classification gating

Classification and releasability constraints enforced on every model and tool call, with tenancy- and classification-scoped retrieval so a query cannot reach a corpus it is not cleared for.

Tool authorization

Every tool invocation is policy-checked, scoped, and recorded. Steps that expand scope or invoke a privileged tool enter an authorization queue rather than executing. No silent shell-outs.

This is what the six functions do. How agents are composed and scoped, what ships and how it deploys, and the full capability inventory are on the ARIA architecture reference.

Evidence Artifact Detail (What an assessor sees)

Evidence

The two artifacts an architect
asks to see.

Not a screenshot of a console. A policy is a versioned, reviewable document owned by your organization, and the audit record is the thing an assessor will actually read.

01 · A policy is a document, not a prompt

policy: release-to-downstream
version: 4        # policy changes are themselves auditable
priority: 200     # higher wins when rules disagree

applies_to:
  actions: [artifact.export, message.send, tool.invoke]

require:
  - classification.releasable_to(request.destination)
  - attestation.present(artifact.version)
  - identity.asserted_by: [CAC, PIV]

on_conflict: deny
on_deny:
  escalate: hitl.gated       # named approver, attributed
  record: policy_decision + evaluated_rules

Declarative, versioned, and organizationally owned. Priority-based conflict resolution when rules disagree, and the resolution is recorded alongside the decision. Illustrative: the schema is representative, not a published specification.

02 · What an assessor reads

2026-09-11T14:22:07Z  POLICY-EVAL   req/a4f1c9e2
  caller     u/j.reyes (CAC, X.509 serial 4F:22:…:A1)
  agent      agent/analysis-02  scope=read:corpus-b
  rules      ITAR-03(p300) CORP-11(p200) release-to-downstream(p200)
  conflicts  0        decision  PASS
  model      provider/model-id  prompt_fp  9c41…e8

2026-09-11T14:22:08Z  HOLD-HITL     req/a4f1c9e2
  reason     artifact.export requires attestation
  mode       gated            approver_role  watch-officer
  sla        04:00:00

2026-09-11T14:26:41Z  ATTESTED      req/a4f1c9e2
  reviewer   u/m.okafor (CAC)  action  accept
  bound_to   artifact/7731 v3  finding/2201
  hash       9f2b…c701        chain_pos  148291

2026-09-11T14:26:41Z  EXECUTED      req/a4f1c9e2
  provenance written · record immutable · revision creates a linked record

Caller and agent identity, the rules evaluated, the policy decision, the model and prompt fingerprint, the attestation and what it was bound to, and the integrity hash with its chain position: enough to reconstruct the outcome without a forensic exercise, and exportable in the formats accreditors accept. Illustrative record. Structure is exact; identifiers are examples.

Product screens live on the Hermes page, where the interface is the thing being claimed. ARIA's interface is whatever your team builds on top of it. Agent composition, deployment components, and the full capability inventory are on the ARIA architecture reference.

Engagement

Bring the architecture you already have.

A technical briefing works best against a real constraint: an existing orchestration investment, a model in an accredited enclave, a network that does not route outbound.

Request a Briefing Read the ARIA overview first

BRIEFING/DISCOVERYYour architecture, your policy set, and where the control plane slots into what you already run.

ScopingWhere it slots in becomes a deployment plan: environment, timeline, and integration points.

DeploymentAir-gapped, on-premises, or authorized cloud, on your timeline.