One closed loop, three moments of truth

Every agent moves through the same lifecycle: verified before it goes live, guarded while it runs, and re-verified whenever it changes.

Stage Sentinel capability Core question Primary output
Before go-live Sentinel Verify Is this agent, as a whole, safe enough to launch? Independent red-team report, security rating, risk boundaries, remediation plan
In production Sentinel Live Is this specific action safe to execute right now? Allow / deny / human-in-the-loop, risk alerts & audit evidence
On change Sentinel Guard Now that the model or environment changed, is it still safe? Impact assessment, automated re-testing, updated evidence & rating
01. Before go-live

Sentinel Verify: independent third-party verification

Verify plays the same role as third-party acceptance testing for critical software, chips or security appliances. We stand on the enterprise's side, independent of the agent vendor, and answer whether the system is ready to hold real authority.

🎯

Scope the boundary

Model version, system prompt, tools, permissions and key workflows, fixed upfront.

🧠

Threat modeling

Attacker capability, access, budget and reuse potential, defined precisely.

⚔️

Adversarial testing

Automated and human-led attacks: injection, hijacking, misuse, exfiltration.

📋

Evidence-based reporting

Cost, capability and evidence required to break the system, quantified.

02. In production

Sentinel Live: real-time runtime judgment

Verify's conclusions are statistical evidence against a defined threat model and test distribution, so they can't guarantee every future action is safe. Once an agent goes live, Sentinel Live sits as a runtime security layer, watching every high-risk action and making a call before it executes.

🔎

Input side

Detects malicious input, indirect prompt injection, content tampering and anomalous context.

🧭

Decision side

Checks whether the current action matches the task goal, history, and the boundaries established at Verify.

🔑

Permission side

Judges whether a tool call, data access or external action exceeds authority or business rules.

Execution side

Low risk: allow. High risk: block, downgrade, or escalate to a human, with the responsible owner notified.

03. On change

Sentinel Guard: why safety has to be re-verified

Agents are highly dynamic software systems. Model upgrades, prompt edits, RAG data changes, new MCP/tools, permission changes, and even improvements in attacker capability can all invalidate a prior safety conclusion. Sentinel binds every safety conclusion to a specific configuration.

📡

Change detection

Model, prompt, RAG, tool, permission and attack-capability changes are tracked continuously.

📊

Impact assessment

Every change is evaluated against the existing rating boundary before anything breaks in production.

🔁

Automated re-testing

Test cases regenerate automatically; Live's real-world interception data feeds the next Verify cycle.

See how Sentinel Verify, Live and Guard fit your stack

Tell us about the agent you're deploying and the authority it needs, and we'll walk through what an engagement looks like.