The Moment Your Infrastructure Drifts, Your Compliance Status Changes. Sentinel Detects Both.

Sentinel prefers API-based collection wherever a service exposes one. Cloud providers, identity platforms, security tools, and SaaS services all expose APIs that Sentinel consumes through typed connectors. AWS accounts connect via read-only IAM roles with scoped cross-account assume-role permissions. Azure subscriptions connect via service principals. Identity providers like Keycloak, Okta, and Azure AD connect via their admin APIs for access review evidence and authentication event logs. Security platforms like AWS Security Hub, Azure Defender, and GCP Security Command Center connect via their finding APIs. Vulnerability scanners, SIEM platforms, ticketing systems. Every connector follows least privilege: read-only access, scoped credentials, no ability to modify infrastructure or access data contents. The monitoring engine does not care what the source is. It issues the same five calls (authenticate, discover, collect, subscribe, healthCheck) and receives the same structured response format.

When APIs do not exist or cannot reach the target, Sentinel falls back to alternative connector types. SSH-based connectors collect from legacy systems and network devices that predate API-driven management. CLI-based connectors run the Redoubt CLI locally inside isolated networks and push results via the BFF API. Import connectors accept manual file uploads for air-gapped environments. The Redoubt Collector Agent (under active development) will provide persistent on-premises collection for environments where periodic CLI runs are insufficient. Every connector type implements the same five-method contract. Adding a new provider means implementing one interface. The connector declares what resource types it can discover, what evidence types it can collect, and what events it can subscribe to. Sentinel registers those capabilities immediately. The architecture is deliberately provider-agnostic because no two infrastructure estates are identical. Your estate spans cloud providers, identity platforms, security tools, and legacy systems. Sentinel connects to all of them through one contract.

Sentinel operates four distinct collection profiles through the same connector infrastructure. Discovery enumerates what exists: every resource, every account, every endpoint across your connected estate. It builds the inventory that Garrison displays. Evidence proves compliance per control: configuration snapshots, policy documents, scan results, access review logs, encryption verification. Each evidence artifact carries a type, a timestamp, a source connector, and a SHA-256 integrity hash. Compliance actively assesses posture against frameworks, benchmarks, and STIGs. It runs CIS Benchmark checks, DISA STIG evaluations, and framework-specific control assessments. Monitoring detects change: configuration drift, new resources, removed resources, permission modifications, encryption state changes.

These profiles are not separate systems. They share connectors, credentials, health checks, and retry logic. A single AWS connector serves all four profiles. Discovery finds an S3 bucket. Evidence collection gathers its encryption configuration, access policy, and versioning state. Compliance checks it against CIS AWS Foundations Benchmark controls. Monitoring subscribes to CloudTrail events for that bucket and fires when its configuration changes. The four profiles represent four questions about the same infrastructure: what do we have, can we prove it is secure, is it compliant, and has anything changed. Sentinel answers all four continuously.

Sentinel ingests findings and events from cloud-native security services and normalizes them into the platform's unified finding format. AWS Inspector vulnerability findings, Security Hub aggregated findings, GuardDuty threat detections, IAM Access Analyzer policy warnings, Config Rules compliance evaluations, and CloudTrail API audit events all flow through the same ingestion pipeline. Each finding is normalized: severity mapped to the platform's taxonomy, affected resources linked to Garrison inventory, and compliance controls mapped via the cross-reference engine. A GuardDuty finding about unauthorized API access is not just a security alert. It is a potential IA-5 (Authenticator Management) control degradation across every active framework.

The ingestion pipeline is not a passive log aggregator. It evaluates every finding against your compliance context. An AWS Config Rule failure on an S3 bucket triggers the same posture re-evaluation as a drift event detected by Sentinel's own monitoring profile. Security Hub findings that map to NIST 800-53 controls are cross-referenced against your active assessments automatically. The platform does not duplicate what cloud providers already detect. It contextualizes those detections within your compliance posture, traces their impact across frameworks, and surfaces remediation priorities in Citadel's action queue. Future phases extend ingestion to Azure Defender, GCP Security Command Center, on-premises EDR platforms, and SIEM event streams.

Collection tasks in Sentinel are organized as a directed dependency graph, not a flat list of scheduled jobs. Each node in the graph represents a collection task. Edges represent dependencies and triggers. When Discovery finds a new S3 bucket, that event triggers SC-28 (Protection of Information at Rest) evidence collection for that specific resource. When a DISA STIG compliance check fails on an EC2 instance, that failure triggers evidence collection for the affected controls. When an evidence artifact expires, its expiration event triggers re-collection from the source connector. The graph is declarative: you define what depends on what, and the engine resolves execution order, parallelism, and cascade propagation automatically.

This architecture eliminates the procedural scripting that plagues traditional monitoring systems. You do not write "when X happens, call Y, then call Z." You declare that evidence collection for SC-28 depends on Discovery having found resources that store data at rest. The engine maintains the graph, watches for triggering events, and schedules downstream tasks. When a single infrastructure change cascades through multiple controls across multiple frameworks, the graph resolves all affected collection tasks in parallel. Cycles are detected at graph registration time. Failed tasks retry with exponential backoff. The graph's current state is always visible: which nodes are running, which are waiting on dependencies, which have failed, and which completed successfully.

Sentinel does not poll every resource at the same interval. The scheduling engine computes collection frequency per resource based on five weighted factors: volatility (how often this resource type changes in your environment), freshness requirements (how current the evidence must be for framework compliance), API quota (how many calls the source connector can sustain), collection cost (compute and network overhead per collection), and compliance impact (how many controls depend on this evidence). A production VPC hosting CUI data with FedRAMP High freshness requirements might collect every 15 minutes. A development VPC with no sensitive data and low volatility might collect daily.

The scheduler recalculates optimal frequencies every 24 hours based on observed patterns from the previous collection cycle. If a resource that was stable starts changing frequently, its collection interval tightens automatically. If a previously volatile resource stabilizes, the interval relaxes. API quota is managed globally across all connectors: if you are approaching rate limits on an AWS account, the scheduler deprioritizes low-impact collections and preserves quota for high-impact ones. The result is a monitoring system that spends its resources where they matter most. No wasted cycles polling static infrastructure. No stale evidence on volatile resources. Every resource runs on its own adaptive clock, tuned to its actual behavior and compliance significance.

Drift detection operates continuously through three complementary channels: AWS Config Rules for configuration state monitoring, EventBridge for real-time event ingestion, and CloudTrail for API-level audit trail analysis. When a resource's configuration changes, Sentinel captures the transition immediately. It timestamps the change to the second. It identifies the actor via IAM ARN, resolving to a human identity when federated through your identity provider. It captures both the previous state and the current state as structured snapshots. Then it evaluates the compliance impact: which controls does this resource satisfy, and does the new configuration still satisfy them.

The evaluation is not a simple diff. Sentinel maps the changed configuration attributes to the specific control requirements they support. An S3 bucket losing its encryption configuration does not just flag "encryption removed." It identifies SC-28 (Protection of Information at Rest), SC-13 (Cryptographic Protection), and any DISA STIG checks that reference that bucket's encryption state. It computes the posture delta: how many controls just degraded, across how many frameworks. Rampart receives the drift event and recalculates posture scores automatically. The finding appears in Citadel's action queue with the actor, the timestamp, the previous state, the current state, and the remediation path. Small changes do not become large findings weeks later. They surface the moment they happen.

When Sentinel detects drift or a compliance degradation, three response modes determine what happens next. Detect mode is the default and the safest: the platform captures the change, evaluates the compliance impact, creates a finding, notifies the responsible party, and waits for human action. Nothing is modified. This is appropriate for environments where changes require manual review, where auto-remediation introduces risk, or where the organization is still building confidence in the platform's detection accuracy. Detect mode produces full audit trail entries: what changed, who changed it, which controls were affected, and what the recommended remediation is.

Fix mode enables auto-remediation for specific resource types and drift categories where the correct response is deterministic. An S3 bucket that loses its encryption configuration is re-encrypted via an SSM automation document. A security group that gains an unauthorized ingress rule has that rule removed. Fix mode is not a global toggle. It is configured per resource type, per drift category, with explicit change windows that define when auto-remediation is permitted. Every auto-remediation action is logged as a compliance event with full provenance: what triggered it, what was changed, and what control it restored. Learn mode observes drift patterns over time without acting on individual events. It identifies recurring drift (the same resource drifting the same way repeatedly), categorizes root causes (manual changes vs. automation conflicts vs. misconfigured IaC), and recommends policy adjustments. Learn mode feeds Artificer's posture reasoning: "This security group has drifted 7 times in 30 days. The root cause is a deployment script that overwrites Terraform state. Recommended: fix the deployment script, not the security group."

Beyond reactive drift remediation, Sentinel can proactively harden your entire environment when you enable it. Proactive hardening analyzes your systems, applications, identity configurations, network policies, access controls, encryption settings, and operational procedures against the controls in your active frameworks. It identifies configurations that satisfy minimum requirements but fall short of best practice. An identity provider with password-only authentication satisfies IA-2 at a basic level, but enabling multi-factor authentication strengthens the control and satisfies additional requirements across CMMC, FedRAMP, and SOC 2 simultaneously. Sentinel surfaces these opportunities ranked by the number of additional controls they would satisfy and the posture improvement they would deliver. When proactive hardening is enabled for a resource type or system component, Sentinel can execute the upgrade automatically within your defined change windows.

Proactive hardening spans the full estate: cloud infrastructure, application configurations, identity provider policies, network segmentation rules, logging and monitoring settings, and access control policies. When the platform detects that a manually configured system could be strengthened with a hardened module from Armory, it recommends the upgrade path. If the organization approves, the platform generates a migration plan: the current configuration, the target configuration, the control delta, and the deployment steps. This is not a one-time scan. The platform continuously evaluates whether your systems and ecosystems could be stronger, whether new hardening options are available, and whether framework updates have changed the control requirements. Proactive hardening turns your monitoring engine into a continuous improvement engine. Detect what is wrong. Fix what is broken. Learn from patterns. Harden what could be stronger.

Sentinel enforces posture thresholds in your CI/CD pipelines through the redoubt-forge/gate GitHub Action and the redoubt-ci GitLab CI template. Pipeline gates query the platform's current posture for the target environment and evaluate it against configurable thresholds. You define the rules: no deployment if posture score drops below 85, no deployment if any HIGH severity findings exist, no deployment if evidence freshness for critical controls falls below 90%. The gate returns pass or fail. On failure, the pipeline stops. The gate output includes the specific controls, findings, or evidence gaps that caused the failure, so your team knows exactly what to fix.

At Developer tier, pipeline gates reference Vanguard scan results and basic posture thresholds. At Guardian tier and above, gates reference the full compliance engine: specific framework controls, evidence sufficiency percentages, drift status, and POA&M compliance. A FedRAMP-bound system can enforce that no deployment proceeds unless all CA-family (Security Assessment and Authorization) controls maintain SATISFIED status with fresh evidence. The gate is not advisory. It is an enforcement point. Your deployment pipeline becomes a compliance control itself, documented and evidenced. The gate execution logs are collected as evidence for CM-3 (Configuration Change Control) and CM-4 (Impact Analyses), closing the loop between your DevOps workflow and your compliance posture.

Every evidence entity in the platform carries an expires_at timestamp computed from the freshness requirements of the frameworks it supports. A daily scheduled job evaluates every active evidence artifact against its expiration date. At 14 days before expiration, Sentinel fires a warning notification to the responsible party and surfaces the aging evidence in Citadel's action queue. For evidence sourced from continuous connectors (AWS Config snapshots, scan results, configuration exports), Sentinel initiates automatic re-collection before the expiration date. The new artifact replaces the old one seamlessly. The control's evidence chain remains unbroken.

For evidence sourced from on-demand processes (manual attestations, policy document reviews, access review sign-offs), automatic re-collection is not possible. Sentinel escalates these through the notification system with increasing urgency: 14-day warning, 7-day warning, 3-day critical alert. If the evidence expires without renewal, the associated control degrades from SATISFIED to AT_RISK. The posture score recalculates. The finding appears in Citadel. The degradation is not silent and it is not gradual. The moment evidence expires, the control status changes. This forces proactive evidence management rather than reactive scrambling during assessment preparation. Your team addresses freshness continuously, not in a panicked sprint before the assessor arrives.

FedRAMP continuous monitoring (ConMon) requirements demand ongoing assessment of security controls, not periodic snapshots. Sentinel implements ConMon natively. Evidence collection runs continuously against FedRAMP baselines (Low, Moderate, High, LI-SaaS). Controls that require monthly vulnerability scanning get monthly evidence refresh cycles. Controls that require continuous configuration monitoring get real-time drift detection. The platform tracks evidence freshness per control against the specific cadence FedRAMP requires: daily for high-volatility controls, monthly for scan-based controls, annually for policy reviews. When FedRAMP 20X mandates machine-readable assessment data, Sentinel produces it from the same evidence stream that feeds your OSCAL compliance packages.

FedRAMP Moderate includes 325 controls. FedRAMP High adds more. Each control has specific evidence requirements and freshness cadences documented in the FedRAMP ConMon guidance. Sentinel maps every control to its evidence sources and collection schedule. The ConMon dashboard in Citadel shows: which controls are current, which are approaching their refresh window, which have fresh evidence collected today, and which are overdue. Monthly ConMon deliverables are assembled automatically: deviation reports, vulnerability scan summaries, incident reports, and POA&M updates. For organizations pursuing FedRAMP authorization or maintaining an existing ATO, Sentinel replaces the manual ConMon workflow entirely. The platform generates the deliverables. Your team reviews and submits.

Not all infrastructure is reachable from the cloud. Air-gapped networks, classified environments, disconnected manufacturing floors, and isolated management VLANs require a different collection model. Sentinel supports three execution modes today and a fourth under active development. CLI collection: the Redoubt CLI bundles all connector implementations locally. Run it on a workstation inside the isolated network, execute discovery and evidence collection against local infrastructure, and export the results as a signed package. Upload the package to the platform when connectivity is available. Pipeline collection: integrate the CLI into automation that runs inside the customer's network. Results push to the platform via the BFF API over VPN or PrivateLink. Import collection: for fully air-gapped environments where no outbound connectivity exists, the CLI produces export files (JSON, OSCAL) that are transferred via approved media (encrypted USB, cross-domain solution) and imported into the platform manually.

The Redoubt Collector Agent is under active development to address the limitations of CLI-based collection for persistent on-premises monitoring. The collector agent is a lightweight, auto-updating service that runs inside your network, maintains persistent connections to local infrastructure (identity providers, network devices, legacy systems), and streams evidence to the platform continuously. Unlike the stateless CLI, the collector agent provides real-time event subscription for on-premises resources: drift detection for local servers, continuous evidence collection from systems that lack cloud APIs, and inventory enumeration across network segments that the platform cannot reach directly. The agent follows the same least-privilege model as cloud connectors: read-only access, scoped credentials, no ability to modify infrastructure. Garrison tracks air-gapped, on-premises, and cloud systems in a single inventory. Compliance controls map identically regardless of collection mode. Evidence from an air-gapped RHEL server carries the same integrity hash, the same timestamp, and the same control mapping as evidence from a cloud instance.