Control the space between intent and execution.
Sentinel gives agent teams an execution-governance layer for the decisions that matter: what the agent can use, what it can expose, when it must stop, and whether a behavioral pattern across turns reveals intent before it becomes action.
Sentinel governs across content modalities and governance layers through one policy surface rather than disconnected point products. What the agent sees, generates, and acts on is all in scope.
Prompt, retrieval, tool output, output, memory, approval, supply chain, runtime, and availability are named governance routes. Sentinel understands where risk is travelling — not just what it looks like at a single event.
Bypass attempts, direct injection, and content designed to manipulate the governance layer itself are screened before the control layer evaluates model behavior. The guardrail is not the first thing that fires — it is what remains after screening.
Gateway routes. PriviShield sanitizes. Sentinel decides. Vault protects access. MKS keeps memory local. Receipts preserve evidence.
Every provider call passes through one governed route. Provider access is not scattered — it is named, visible, and scanned.
PII, secrets, and unsafe prompt material are detected and redacted before model exposure. A receipt hash is produced for every pass.
Behavioral governance runs in the decision path. Allow, flag, review, block, or redact — before the provider receives the request.
Credentials stay outside model context through zero-knowledge access design. The agent requests — it does not receive the raw secret.
User memory stays on-device, encrypted with a device-bound key. The server processes the control path without holding plaintext memory.
Every decision is receipt-backed. The audit log is hash-chained — any modification breaks the chain and is detectable.
Every prompt, retrieval, tool call, memory write, approval, output, runtime event, and availability signal enters a named pathway. PriviShield sanitizes before model exposure. Sentinel decides whether the agent continues, stops, escalates, or returns with evidence. Provider responses are governed on the way back before they reach the agent.
Open the architecture →Agents do not fail through one surface. They fail through the path between prompt, tool, memory, credential, output, and provider. Sentinel maps those surfaces into one control plane, so execution can be governed as a system.
Prompt risk can become tool risk. Tool output can become memory risk. Retrieved content can become execution risk. Sentinel keeps those transitions visible instead of treating each surface as a separate scanner.
Prompt integrity, output governance, tool-use governance, trajectory analysis, provenance analysis, and behavioral baseline.
Text, code, audio, vision, temporal, and credential surfaces classify the material moving through the agent path.
Twelve detection surfaces governed, audited, and enforced together — not twelve disconnected scanners.
Each pathway is an explicit governance route, not a label. Sentinel keeps the request, retrieval, tools, memory, approvals, and outputs inside a named control path where risk is tracked by route and sequence — not just by shape.
The instruction itself. Injection, jailbreak, role drift, and instruction residue are handled before the model sees the request.
M01Risk examplesJailbreak phrasing, delegated instructions, hidden overrides.
Governed actionNormalize and evaluate the prompt before provider routing continues.
Why it mattersPrompt is where agent intent first becomes executable.
RAG and retrieval evidence. Poisoning, provenance, freshness, and document integrity checks become part of the control path.
M05Risk examplesPoisoned passages, stale evidence, untrusted document fragments.
Governed actionEvaluate retrieved material before it is merged into model context.
Why it mattersRetrieval can quietly import risk from outside the agent.
What tools return. Sanitization, exfiltration screening, and unbounded output containment are applied on the way back in.
M03Risk examplesOversized responses, hostile markup, leaked tokens, tool-return instructions.
Governed actionScreen tool results before they become the next model input.
Why it mattersTool output can become an attacker-controlled prompt.
What the model emits. Sensitive content, exploit payloads, prompt theft, and unsafe output patterns are governed at the boundary.
M02Risk examplesCredential echoes, harmful instructions, unsafe code, policy-evading responses.
Governed actionInspect the response before it is returned or handed to another system.
Why it mattersThe final answer is still part of the execution path.
Persistent and session memory. Poisoning, embedding integrity, and memory-resident instructions are screened on write and read.
M11Risk examplesStored jailbreaks, corrupted embeddings, stale user state.
Governed actionGovern memory writes and reads as protected state changes.
Why it mattersMemory turns a single event into future behavior.
Human-in-the-loop gates. Privilege escalation, authority laundering, and unsanctioned sub-agent requests are checked before sign-off.
M03Risk examplesFake approval context, tool escalation, delegated authority abuse.
Governed actionRequire the approval path to carry risk context, not just a yes/no action.
Why it mattersApprovals are where autonomy becomes permission.
Plugins, tools, and model assets. Tampering, backdoors, and insecure plugin surfaces are treated as supply-chain risk.
M05Risk examplesCompromised tools, altered plugins, untrusted model assets.
Governed actionEvaluate tool and asset provenance before they join the agent path.
Why it mattersAgents inherit risk from every component they can call.
Execution state. Behavioral baselines, service identity drift, and unbounded execution are contained in the hot path.
M06Risk examplesUnexpected identity changes, runaway tool loops, state drift.
Governed actionCompare behavior to known execution posture while the run is active.
Why it mattersRuntime drift is often visible before a failure becomes obvious.
Resource exhaustion and DoS posture. Model DoS, cost attacks, and resource-burn patterns are treated as a governed pathway.
M06Risk examplesToken flooding, retry loops, expensive tool chains.
Governed actionLimit abusive patterns before they consume budget or capacity.
Why it mattersAvailability is a control surface, not only an infrastructure metric.
Sentinel does not ask only "is this event safe?" It asks "what is this behavior becoming?" A single request can look harmless. A sequence can reveal intent — especially when events span turns, tools, and sessions.
Slow-burn risk is the kind most likely to evade single-event governance. Sentinel is designed to see it before it becomes execution.
Sentinel detects ordered patterns across turns: when one behavior follows another in a recognizable escalation, the chain is flagged — not the individual step. Order matters.
When an agent delegates to a tool that delegates further, Sentinel follows the call ancestry. Risk can propagate across a tool call tree in ways single-event analysis never sees.
History carries across the full mission context. An early probe, followed by benign turns, followed by an exploit — is still a probe-to-exploit trajectory. Sentinel does not forget.
Chain detections produce evidence receipts. The behavioral sequence that led to a block can be replayed, inspected, and handed to security teams as a verifiable record.
You cannot govern agents from the sidelines. Once the request has reached the provider, the tool has executed, or the credential has entered context, you are already downstream of the decision. Sentinel puts control inside the path before execution continues and before incidents become yours to own.
If your agents can call tools, touch customer data, write memory, use credentials, or route to model providers — Sentinel gives you a governed path before those actions continue. No security team required to get started.
For founders, SME CTOs, and product teams shipping agent workflows: Sentinel installs as a controlled route, not a compliance program. Wire it into a test agent, inspect the control path, and prove decisions before you scale.
Your agents are starting to act. They can call tools, touch customer data, write memory, use credentials, and send requests to model providers. Sentinel gives those actions a controlled path before they continue.
Most teams do not lose control because one prompt looks dangerous. They lose control because small actions connect over time.
Safe agent deployment starts with owning the control path: the requests that leave, the responses that return, the tools that execute, the credentials that stay protected, and the decisions recorded before execution continues.
Register interest for launch access, product fit, and follow-up with the Aera team.
Sentinel sits in the control path between agent activity and provider continuation. It works with Gateway, PriviShield, Vault, MKS, and receipts so prompts, tools, memory, credentials, outputs, and provider responses are governed, controlled, and recorded before execution continues.
No. Prompt filtering usually looks at one input and tries to clean it up. Sentinel controls pathways across prompt, retrieval, tool output, output, memory, approval, supply chain, runtime, and availability. It also tracks behavior across turns, tools, sessions, and temporal chain families, where embedded and multimodal risks can move from one surface to another.
Gateway gives agent and application traffic one controlled route to model providers. Instead of provider calls scattering across tools, SDKs, services, and API keys, Gateway centralises the path so requests can be scanned, controlled, recorded, and continued only when approved. It is the routing layer that makes provider access visible before Sentinel applies execution control.
No. Sentinel is designed to control the path to providers, not replace them. Gateway gives provider calls one controlled route so requests can be scanned, governed, controlled, recorded, and continued only when approved.
PriviShield detects and sanitizes PII, secrets, unsafe prompt material, and encoded credential-like content before model exposure. It redacts sensitive material, produces receipt evidence for the sanitized pass, and helps stop provider-bound requests from carrying data the model should never see.
Vault keeps credentials, API keys, OAuth grants, and sensitive access material outside model context. Agents can request access, but they should not receive raw secrets. Vault stores protected material as encrypted data tied to key material and access context, so captured ciphertext is not useful without the required keys and authorised session path. For agent systems, credentials are not just data. They are execution rights.
Not by default. Sentinel is designed around evidence rather than raw conversation storage: receipts, hashes, verdicts, pathway metadata, scan results, and audit records. Managed evidence retention is opt-in.
The action stops before continuation. Sentinel returns a controlled decision with evidence, so operators can see what pathway was involved, what policy applied, and why the action did not continue.
Yes. If your agents can use tools, touch customer data, write memory, use credentials, or call providers, you need a control path. Sentinel gives small teams execution control that is usually reserved for larger security organisations.
Provider guardrails live inside someone else’s model boundary. Sentinel gives you your own control path before and after provider calls, with visibility across tools, memory, credentials, receipts, and agent behavior over time. Provider guardrails can be affected by long-running sessions, context pressure, and provider-side limits. Sentinel sits outside the model boundary, so the control path does not depend on the model remembering its own guardrails.
