Sentinel Guard 2.0.0

Sentinel 2.0.0: Sentinel Guard, the safe-action layer for any AI agent. No agent changes production unless policy, or the right people, approved that exact change, and then it runs once. Every decision is signed and provable to others. Sentinel's own incident copilot runs on it.

Try it in one command

git clone https://github.com/abdulmdev/sentinel-incident-copilot && cd sentinel-incident-copilot
docker compose up        # then open http://localhost:8080 as Alice (token alice-demo) or Bob (bob-demo)

Install on Kubernetes

helm install sentinel-guard oci://ghcr.io/abdulmdev/charts/sentinel-guard --version 2.0.0 -n sentinel-system --create-namespace

Or kubectl apply -f install.yaml (attached below). The kubectl plugin is attached too (kubectl-sentinel_<os>_<arch>.tar.gz), or install it with krew. The Python SDK (wheel) and the TypeScript SDK (npm tarball) are attached as well. The image and the chart are signed with cosign (keyless).

What's in v2

• Enforcement at the Kubernetes API:
  • an admission webhook holds agents' changes (coding agents with kubectl, CI bots, any agent) with no code changes;
  • an approval admits exactly that change, once, including across the API server's own retries;
  • humans, CI and controllers are never slowed down;
  • if the guard is down, only agents are stopped.
• Any agent, anywhere:
  • Python and TypeScript SDKs;
  • a LangChain/LangGraph tool wrapper;
  • a zero-code MCP proxy that puts the guard in front of any MCP server's tools.
• People decide, as themselves:
  • in Kubernetes with kubectl sentinel approve;
  • elsewhere with personal tokens or OIDC tokens the guard verifies;
  • in an inbox with an Overview of every agent's actions and the full story of each request.
  • The riskiest actions can require two or more different people (approvals: N).
  • Notifications go to Slack-style webhooks.
• Provable to others:
  • every request, decision and execution is a signed link in a hash chain;
  • kubectl sentinel audit export produces one evidence file anyone can verify offline, against a pinned key and an archived export;
  • every replica re-verifies the chain, and tested alert rules flag drift in each agent's behaviour;
  • mapped to the EU AI Act and the NIST AI RMF (docs/compliance).
• SafeActionBench, an open benchmark for harmful agent actions. An independent guard alone took a small model from 33.9% harmful to 0%.

New since 2.0.0-alpha.3

• Two-person approvals, approvers verified by OIDC, delegates forwarding the person's token, and notifications.
• The inbox's Overview and per-request details, with deep links.
• An incident whose guard request is gone can be closed. Alerts never join an incident that has ended.
• A fresh read before "pending", so an approval made a moment ago through another replica counts at once.
• The API is stable: sentinel.dev/v1. v1alpha1 is still served, deprecated.

Upgrading from an alpha

kubectl apply -f https://raw.githubusercontent.com/abdulmdev/sentinel-incident-copilot/v2.0.0/deploy/helm/sentinel-guard/crds/actionrequests.sentinel.dev.yaml
helm upgrade sentinel-guard oci://ghcr.io/abdulmdev/charts/sentinel-guard --version 2.0.0 -n sentinel-system

helm upgrade never updates CRDs. A 2.0.0 guard on the old CRD stops, and its log says exactly what to apply. Then kubectl -n sentinel-system rollout restart deploy/sentinel-guard, and wait until the alpha's pods have finished terminating before approving anything. Those pods lack 2.0.0's preStop pause, so a webhook call routed to one that has stopped would time out. Records from the alpha releases are read through v1 and keep verifying, and requests pending across the upgrade can still be approved. CI tests this path from 2.0.0-alpha.3 on a real API server.

Measured

• On a real API server: 33/33 end-to-end checks, and the upgrade test.
• Latency (p99, 3 replicas, through the API server):
  • an approved change admitted once: 34.6 ms;
  • an agent change waiting for approval: 7.5 ms;
  • a human's change: 6.1 ms.
• The docker compose quickstart: 29/29 checks in CI.
• 331 automated tests.

Docs: docs/guard/README.md · design: handbook chapter 17 · decisions: ADR-0010 to ADR-0018

Sentinel Guard 2.0.0-alpha.3

Sentinel Guard 2.0.0-alpha.3: any agent, provable records, one command to try. SDKs and a zero-code MCP proxy for agents outside Kubernetes; a signed evidence export anyone can verify offline; guardian alerts on agent drift; and docker compose up with a live agent and an approvals inbox.

Try it

git clone https://github.com/abdulmdev/sentinel-incident-copilot && cd sentinel-incident-copilot
docker compose up        # then open http://localhost:8080, token approve-me

Install

helm install sentinel-guard oci://ghcr.io/abdulmdev/charts/sentinel-guard --version 2.0.0-alpha.3 -n sentinel-system --create-namespace

Or kubectl apply -f install.yaml (attached below). The kubectl plugin is attached too (kubectl-sentinel_<os>_<arch>.tar.gz), or install it with krew. The Python SDK (wheel) and the TypeScript SDK (npm tarball) are attached as well.

New since alpha.2

• SDKs and the MCP proxy.
  • Python and TypeScript SDKs: require, then spend, or a decorator.
  • A LangChain/LangGraph tool wrapper.
  • sentinel-guard-mcp-proxy, which puts the guard in front of any MCP server's tools with no code.
• Evidence export.
  • kubectl sentinel audit export (or GET /v1/audit/export for policy auditors) writes one self-verifying file.
  • kubectl sentinel audit verify --bundle checks it offline, against a pinned key (--jwks) and an archived export (--previous).
  • Each request now names the version of the policy it was decided under, and chain heads are signed.
• Guardian monitoring.
  • Every replica re-verifies the audit chain.
  • New metrics: per-agent outcomes, the approval backlog and chain health.
  • prometheusRule.enabled=true installs 8 alerts: integrity, oversight lapses, and drift in each agent's behaviour.
  • grafanaDashboard.enabled=true adds the Sentinel Guard dashboard.
• An approvals inbox in single-process mode (docker run, docker compose). Open the guard's URL to approve or deny in a browser, verify the chain, and download the evidence.
• sentinel-guard -healthcheck, for container health checks.
• Fixed: the CRD lacked spec.decidedVia, so delegated decisions lost it in Kubernetes mode.
• The chart is now signed with cosign, like the image.

Measured

• Guard end to end on a real API server: 31/31 checks, including tampered evidence and the guard taken down. p99 for an approved change admitted once: 40.8 ms (3 replicas).
• Evidence: verifying 1,000 requests (3,000 events) takes about 0.18 s; the bundle is about 2.1 KB per request.
• The quickstart: 18/18 checks in CI, with Prometheus and Grafana.
• 307 automated tests.

Upgrading from alpha.2: requests recorded by older guards carry no policy version and their head is unsigned. Both still verify, with a note.

Alpha: the API and the CRD (v1alpha1) may change.

Docs: docs/guard/README.md · design: handbook chapter 17 · governance: docs/compliance · decisions: ADR-0012, ADR-0014, ADR-0015

Sentinel Guard 2.0.0-alpha.2

Sentinel Guard 2.0.0-alpha.2: one safety core. Sentinel's own incident copilot now runs on Sentinel Guard. The agent proposes, the console's approvals are recorded in the guard, and the remediation adapter redeems the guard's single-use capability.

Install

helm install sentinel-guard oci://ghcr.io/abdulmdev/charts/sentinel-guard --version 2.0.0-alpha.2 -n sentinel-system --create-namespace

Or kubectl apply -f install.yaml (attached below); the kubectl plugin is attached too (kubectl-sentinel_<os>_<arch>.tar.gz), or via krew. Try it without a cluster: docker run -p 8080:8080 ghcr.io/abdulmdev/sentinel-guard:2.0.0-alpha.2.

New in alpha.2

• Delegated decisions. A service that signs people in (a console, a chat bot) can record their approvals over HTTP. List it under delegates; the decision is recorded as the person's, via that service, and the audit shows both. A delegate can never approve for the agent that asked.
• Approved parameters travel with the capability. Capabilities now carry namespace and change (the approved parameters), so executors check that they run exactly what was approved (e.g. a pool size of 40, not 60).
• An in-cluster action API port (api.plainHTTP, SENTINEL_GUARD_API_ADDR) without the admission webhooks, for clients in other namespaces.
• The copilot on the guard (Sentinel 0.7.0 chart): the guard is a dependency of the sentinel chart. The agent and gateway get their own ServiceAccounts and short-lived projected tokens; a NetworkPolicy covers the guard.

Measured (live, local stack):

• Closed loop: alert → incident in 27 s → rollback approved in the console → verified healthy, time to mitigate 24.4 s.
• Audit: the guard's chain verified, with the request by the agent, the approval by the reviewer via the gateway, the capability issued, and the execution by the adapter.
• Guard down: with the guard stopped, an approval returned 503 and nothing ran.
• Tests and CI: 252 automated tests. CI ran the copilot end to end on Kubernetes through the guard, plus the guard's 25 checks.

Alpha: the API and the CRD (v1alpha1) may change.

Docs: docs/guard/README.md · design: handbook chapter 17 · decisions: ADR-0010, ADR-0011

Sentinel Guard 2.0.0-alpha.1

Sentinel Guard: envelope protection for AI agents. No agent changes your cluster unless policy, or a human, approved that exact change, and then only once. Humans, CI and controllers are never sent to the guard.

This is the first (alpha) release of Sentinel v2: Sentinel's safety core, extracted so that any agent is held to it, without code changes.

Install

helm install sentinel-guard oci://ghcr.io/abdulmdev/charts/sentinel-guard --version 2.0.0-alpha.1 -n sentinel-system --create-namespace

Or kubectl apply -f install.yaml (attached below). The kubectl plugin is kubectl-sentinel_<os>_<arch>.tar.gz below, or via krew:

kubectl krew index add sentinel https://github.com/abdulmdev/sentinel-incident-copilot.git && kubectl krew install sentinel/sentinel

Try it without a cluster: docker run -p 8080:8080 ghcr.io/abdulmdev/sentinel-guard:2.0.0-alpha.1.

What's in it

• Enforcement at the Kubernetes API:
  • a validating webhook, sent only agent identities (matchConditions), which fails closed for them;
  • approvals as ActionRequest objects, decided through RBAC with kubectl sentinel approve;
  • the approver is stamped from the authenticated identity.
• Exactly once:
  • an approval is bound to agent + action + target + the exact change;
  • consumed by compare-and-swap;
  • the API server's own write retries are recognised (identical object, same generation).
• Tamper-evident audit: a signed hash chain, verifiable by anyone with read access (kubectl sentinel audit verify), which also detects deleted records.
• An HTTP action API for agents outside Kubernetes: propose → approve → a single-use ES256 capability → the executor spends it.
• Operations: 3 replicas, no database, self-provisioned TLS and signing key, a watch cache, one housekeeping lease.
• Supply chain: a multi-arch image (amd64, arm64), signed with cosign (keyless), with SBOM and provenance.

Measured (fresh kind cluster, 3 replicas, p99 through the API server):

• a human's change: 4.9 ms;
• an agent's pending change: 4.6 ms;
• an approved change admitted once: 42.9 ms.

The 25 end-to-end checks pass on a real API server.

Alpha: the API and the CRD (v1alpha1) may change. Known limits are in the docs (retention, the single chain head, only the configured operations are guarded).

Docs: docs/guard/README.md · design: handbook chapter 17 · decision record: ADR-0010

Sentinel 1.0

Sentinel 1.0: an incident-response copilot that closes the loop. Alert → investigation → cited proposal → human approval → exactly-once fix → verified recovery.

Highlights

• Closed loop: Alertmanager opens incidents (deduplicated, correlated per service). Approval mints a single-use, 5-minute capability; the remediation adapter executes exactly that action once; real-traffic probes verify recovery. Time to mitigate: 14–41 s in live runs, human approval included.
• Agent: LangGraph with durable Postgres checkpoints, MCP tools and hard budgets; Claude, a local model (Ollama), or rules.
• Safety, measured: on 112 replayed incidents, a local 8B model (gemma4) proposes a harmful fix in 33.9% of incidents; with deterministic guardrails (input sanitization, citation validation, runbook preconditions) 0% reach a human. The rule baseline scores 92.9% correct, 0 harmful. A CI gate fails the build on regression.
• Zero-trust identity: OIDC users (Keycloak); ES256 service tokens minted only by the gateway, verified everywhere via JWKS; every hop authenticated and tenant-bound; row-level security including agent checkpoints.
• Platform: Spring Boot 4 + Spring AI 2 gateway; Kafka ingestion with hybrid retrieval (pgvector + full-text, RRF); Redis rate limits; OpenTelemetry traces; Grafana.
• Deploy: Docker Compose, Helm (hardened pods, NetworkPolicies) verified on kind in CI, Terraform for AWS; multi-arch images on GHCR.
• 212 automated tests, plus a real Kubernetes end-to-end test in CI.

Get started

• User guide · Website · Write-up
• The engineering handbook (architecture, security, operations, and the full build history) is attached as a PDF.

Container images: ghcr.io/abdulmdev/sentinel-<service>:<commit>.