Skip to content

ADR-0006: Continuous Verification and Monitoring

  • Status: Accepted
  • Date: 2026-08-01

Context

A request that is authorized at the start of execution may become unsafe later. Identity state may change, credentials may be revoked, approvals may expire, connector health may degrade, policy may change, anomalous behavior may emerge, or the execution path may diverge from the approved scope.

A one-time authorization decision is therefore insufficient for long-running, multi-step, or high-impact AI workflows.

Decision

AegisLayer adopts continuous verification and monitoring across the request and execution lifecycle.

Trust is not permanent. Identity, authority, policy, approval, connector readiness, capability scope, runtime state, and security context must be re-evaluated whenever material conditions change.

The architecture should continuously observe, where applicable:

  1. Identity, session, workload, and device state.
  2. Approval validity, scope, and revocation status.
  3. Policy version and risk context.
  4. Connector health, compatibility, and readiness.
  5. Capability expiry, use, and attempted scope expansion.
  6. Tool-call sequences and execution behavior.
  7. Resource consumption, latency, failures, retries, and cost.
  8. Data access, output classification, and possible exfiltration.
  9. Evidence continuity, sequence integrity, and missing records.
  10. Security alerts, anomalies, and incident indicators.

A material change in trust conditions may trigger:

  • Re-evaluation.
  • Additional approval.
  • Capability narrowing.
  • Credential rotation or revocation.
  • Execution pause, cancellation, or containment.
  • Connector suspension.
  • Human or specialist escalation.

Rationale

Continuous verification and monitoring:

  • Reduces reliance on stale authorization decisions.
  • Supports Zero Trust principles.
  • Detects drift between approved intent and actual execution.
  • Improves containment of compromised agents, connectors, or credentials.
  • Strengthens evidence and incident reconstruction.
  • Enables policy and approval revocation during execution.

Considered Alternatives

One-Time Authorization

Validate trust only before execution begins.

Rejected because: trust conditions can change after authorization, especially in multi-step workflows.

Periodic Monitoring Without Enforcement

Collect telemetry but do not change execution behavior automatically.

Rejected as insufficient because: detection without an authorized containment path leaves harmful actions active.

Continuous Verification with Governed Response

Continuously assess trust and permit explicit revocation, cancellation, containment, or escalation.

Accepted because: it aligns monitoring with enforceable governance controls.

Consequences

Benefits

  • Faster anomaly detection and response.
  • Reduced impact of revoked or compromised credentials.
  • Better enforcement of time-limited approvals.
  • Stronger visibility across long-running workflows.
  • Improved operational and forensic evidence.

Trade-offs

  • Additional telemetry, storage, and processing overhead.
  • Greater system complexity.
  • Risk of false positives interrupting legitimate work.
  • Monitoring services become security-critical dependencies.
  • Privacy and data-minimization requirements must be considered.

Residual Risks

  • Novel attacks may not match existing detection logic.
  • Monitoring data may be incomplete, delayed, or manipulated.
  • Automated containment may interrupt important legitimate operations.
  • Excessive telemetry may expose sensitive operational information if not protected.

Acceptance Criteria

  • Long-running or multi-step execution supports re-evaluation.
  • Expired or revoked approvals and capabilities stop further use.
  • Connector health changes can prevent or interrupt invocation.
  • Policy violations and material anomalies produce evidence and response actions.
  • Monitoring events are correlated with requests, workflows, approvals, and execution records.
  • Containment and revocation paths are explicit and testable.
  • Monitoring failures do not silently convert into trusted execution.

Operational Guidance

Implementations should:

  • Define which context changes require re-authorization.
  • Use bounded, deterministic response policies where possible.
  • Separate observation, decision, and enforcement responsibilities.
  • Protect telemetry and incident data from unauthorized access or alteration.
  • Test revocation, expiry, anomaly, and monitoring-outage scenarios.
  • Minimize collected data to what is necessary for security and governance.

Public Release Review

This ADR describes public architectural principles only. It excludes internal detection thresholds, customer telemetry, production monitoring rules, credentials, and security-sensitive deployment details.