How did Project Sentinel become the foundation for ConstatAI?
Project Sentinel established a focused AWS detection, response, and observability foundation. ConstatAI develops that work into an AIOps and DevSecOps assurance application: collect evidence, support investigation, govern proposed actions, verify outcomes, and preserve the record. Sentinel remains its primary monitoring, review, and reporting workflow. The application is in development; documented implementation and lab results do not establish production readiness.
Project Sentinel started with a concrete engineering problem: connect an AWS security event to an appropriate response, then leave evidence an operator could inspect. That focus made the relationship between infrastructure, application behavior, and operational visibility tangible.
ConstatAI carries that foundation into a broader application. A reviewer needs to understand the event, evaluate the proposed response, identify who has authority to approve it, and inspect what happened afterward. The evolution is an expansion of the engineering problem: from handling a signal to making the whole decision and response workflow reviewable.
Start with a bounded response system
The original Sentinel README describes CloudTrail events routed through EventBridge, with a Python Lambda handling supported S3 repairs and IAM alerts. CloudTrail tampering and root activity have direct SNS notification paths. Terraform defines the infrastructure, while CloudWatch metrics, structured logs, and X-Ray expose execution behavior.
The README also records a practical repair: keeping the self-trigger guard inside Lambda rather than relying on an EventBridge identity filter that excluded legitimate events. It documents automatic and alert-only modes, failure queues, and development tests. Those are implementation records, not a current performance benchmark.
The lesson I carry forward is to follow an event through the response and inspect the resulting evidence. A function returning successfully is only one observation. Whether the intended resource changed, whether a notification arrived, and whether the record supports investigation are separate questions.
Give the reviewer a coherent workspace
ConstatAI keeps Sentinel as its primary monitor, review, and report workflow. The Notion project record describes a workspace for reviewing AWS findings by category, examining actor and target context, refreshing visible evidence, and exporting an authenticated report. The application uses Nuxt and TypeScript to bring that review experience together.
The important change is the unit of work. An operator needs more than an alert count: which identity acted, which resource was involved, when the evidence was collected, and what the response record actually establishes. The product requirements extend that idea toward correlated incidents with traceable source evidence.
That distinction also sets a boundary on the product story. The project notes identify incident, agent, and remediation experiences that still contain sample workflows. An implemented review screen, a representative incident, and an executed cloud action each need their own evidence and status.
Separate AI interpretation from action authority
The ConstatAI notes state the operating rule directly: “AI explains and recommends. Deterministic controls authorize and enforce.” AI can help explain evidence and propose a response. Permission to act must come from independently enforced identity, policy, target scope, and approval requirements.
The draft PRD describes a target sequence: input, evidence collection, deterministic assessment, AI explanation, proposed action, policy or approval check, execution, verification, and audit record. That sequence is a design contract for the application. It is not a claim that every transition is already connected and accepted in production.
Consider a proposed repair to a cloud resource. A convincing explanation should not widen the executor’s permissions or lower the required approval level. The control decision needs to hold even when the model is confident, an input is malformed, or evidence is incomplete. Model confidence and authorization answer different questions.
Treat evidence as part of the architecture
The ConstatAI AWS case study documents a source implementation that routes events through encrypted SQS to Python Lambda, preserves evidence in S3, records findings in DynamoDB, and sends reference-only SNS alerts. It also describes conditional evidence creation and checks that reject conflicting content for a reused event identifier. These controls address how evidence enters and survives the workflow.
A separate CloudTrail baseline check compares observed settings with the approved configuration. Its purpose is to avoid depending entirely on the event stream whose logging state is under review. The notes also acknowledge that the checker remains inside the same AWS account and failure boundary. That limitation belongs beside the design.
The review interface needs equally explicit limits. ConstatAI’s notes describe bounded scan results, collection times, retrieval gaps, and unavailable metrics. A displayed hash does not independently verify integrity. An empty category does not prove that a threat was absent. Evidence should help a reviewer understand both the observation and its coverage.
Define what a verified recovery would mean
The PRD uses Étalon for the approved reference state against which a response should be checked. This gives verification a specific object: compare the observed result with an agreed state, rather than treating an execution message as completion.
The documented CloudTrail recovery design is deliberately bounded. Its optional SSM Automation path is disabled by default, uses a separate identity, requires a named human approver, and restricts recovery to starting logging on the exact trail. Changed configurations or a deleted trail cause the runbook to stop. The project record identifies this as source implementation with live recovery verification still incomplete.
That is a useful direction for the wider application. A proposed action, an approval, an execution attempt, and a verified outcome should remain distinct states. The reviewer should be able to see where the workflow stopped and which evidence would be required to proceed.
Keep validation tied to the system it tested
The October 22 ConstatAI update links a CI checkpoint covering application tests, evaluation fixtures, multiple build targets, provenance checks, and security tooling. It also records temporary dependency backports with an expiry and upstream replacement work still open. A passing checkpoint has a source version, an environment, and limitations; it should be read with all three.
This matters when the project spans a browser interface, authentication, policy storage, packaged server code, and cloud infrastructure. Mocked infrastructure tests can exercise a policy path without proving effective deployed permissions. A build manifest can connect an artifact to reviewed source without independently proving that the hosted application serves that artifact.
The notes apply the same discipline to AI tooling. Using review agents and a GitHub MCP connector during development does not establish that ConstatAI has a governed hosted agent runtime. Development assistance, a product preview, and accepted runtime behavior need separate descriptions.
Include shutdown in the operational record
The latest operational checkpoint in the Notion notes is October 22. It records the AWS and Azure test labs shut down, local runtimes stopped, and cloud-backed sign-in and testing offline. Source and hosting were retained. Those dated conditions qualify the earlier lab results; this article does not independently establish the application’s current live availability.
The Azure shutdown record also preserves a correction: a platform-created Network Watcher outside the Terraform test group was missed initially and removed after follow-up inventory. The lesson is broader than teardown. A tool’s state describes its own coverage, which may leave out resources created through another path.
For ConstatAI, that reinforces a central requirement: show what was checked, what remains unknown, and how a conclusion was verified. A failed or partial read should remain visible as an evidence gap. Operational records become more useful when they preserve corrections as well as successful checks.
Build the next milestone around one complete path
ConstatAI’s PRD sets a focused next milestone: a production-quality read-only AWS evidence path, traceable incident context, verified role boundaries, and evaluations for grounded explanation and safe fallback. The project record leaves broader hosted acceptance, durable action history, autonomous agents, and end-to-end recovery verification incomplete.
I want the next increment to answer a small set of concrete questions. Can a reviewer trace a finding to its source? Can the interface distinguish stale or missing evidence? Can an unauthorized identity be shown to fail? If an action is eventually approved, can the system preserve the decision and demonstrate the resulting state?
That is the connection between Sentinel and ConstatAI. The original project made cloud response observable. The application carries that discipline into investigation, authorization, and verification. Each capability should earn its place through a working path and evidence another person can inspect.
Sources reviewed November 8, 2026. The ConstatAI project record includes October 22 operational updates; the PRD is a September 18 draft. Architecture, historical test results, and planned capabilities are distinguished throughout. Neither project’s application tests or cloud infrastructure were exercised to write this article.