Why the path matters.
Most AI safety layers live inside the model, inside the prompt, or beside the runtime as observation. Sentinel is built differently. It controls the path the agent must use to reach providers, tools, credentials, and responses. The control point is not another instruction the agent can reason about. It is infrastructure the request must pass through.
Why Sentinel sits in the path.
Not beside it.
Sentinel controls the runtime path between agents and providers. The point is not to add another instruction around the agent. The point is to control the route the request must use before provider continuation.
Provider guardrails and prompt-level constraints are useful, but they live close to the model behavior they are trying to control. In long-running agent systems, constraints that appear inside the task context can become part of the problem the agent is trying to solve around.
Side observers have a different problem: they can see activity, but they may only react after the request has moved, the tool has executed, or the provider has already returned content. Observation is not the same as control.
Sentinel sits in the hot path. The agent does not call the provider directly. The request enters Gateway, passes through PriviShield and Sentinel Edge, and continues only if the control path allows it. The same path governs provider responses before they return to the agent.
This matters because the agent can attempt the task, but the signal still has to pass through the path. The control point is not exposed as a prompt instruction or harness rule for the agent to reason about.
Provider guardrails
Useful baseline protection, but they operate inside someone else’s model boundary and may not understand your tools, credentials, custody rules, or agent mission context.
Harness constraints
Useful for shaping behavior, but visible constraints can become obstacles inside the agent’s execution context.
In-path control
Controls the route itself. Sentinel can stop, redact, review, flag, or allow before provider continuation and again before responses return to the agent.
The provider call is not the end of the path.
Responses are governed on the way back.
A request can be safe on the way out and dangerous on the way back. Tool output, retrieved content, provider responses, and generated instructions can carry injection, disclosure, unsafe code, or credential-seeking behavior. Sentinel treats the return path as part of the same control path.
Outbound request
Provider-bound content is routed, sanitized, evaluated, and either allowed, flagged, reviewed, blocked, or redacted before provider exposure.
Inbound response
Responses and tool returns are evaluated before the agent receives them, so unsafe or sensitive material can be controlled on the return path.
Nine pathways show where risk moves.
Each pathway can be controlled differently.
Pathways are not marketing categories. They identify where agent risk enters, moves, returns, persists, or consumes resources so policy can act on the right part of the runtime path.
pathway 01PromptInstructions entering the agent/provider path.
user, system, developer, tool, or agent-generated instruction material entering the provider path.
injection, jailbreak attempts, role confusion, hidden instructions, or instruction residue can redirect the agent before execution starts.
Sentinel controls whether the instruction continues, is sanitized, is flagged, is escalated, or is blocked.
the instruction path has signs of unsafe control transfer, manipulation, or policy conflict.
pathway 02RetrievalDocuments, RAG output, search results, and external context brought into the run.
retrieved text, documents, search results, support tickets, knowledge-base entries, or external evidence added to the agent context.
a document can be trusted because it was retrieved from an approved source while still containing instructions or poisoned content that the model treats as task context.
Sentinel controls provenance checks, freshness checks, source trust, poisoning signals, and whether retrieved content is allowed to influence execution.
the retrieved material may be unsafe, stale, poisoned, untrusted, or attempting to alter the agent’s instructions.
pathway 03Tool outputData returned from tools, APIs, scripts, plugins, databases, or external services.
data returned from tools, APIs, scripts, plugins, databases, or external services.
tool output can contain injection, over-broad data, unexpected secrets, malicious payloads, or instructions disguised as results.
Sentinel controls whether the tool result is allowed back into the agent context, sanitized, summarized, blocked, or escalated.
the output from a tool is not safe to treat as normal context without control.
pathway 04OutputText, code, tool instructions, summaries, or actions the model is about to return.
text, code, tool instructions, summaries, or actions the model is about to return.
the model may produce unsafe code, disclose sensitive material, generate policy-violating instructions, or attempt to route the user toward unsafe action.
Sentinel controls whether the output is allowed, redacted, rewritten, flagged, blocked, or sent for review.
the response itself carries execution, disclosure, safety, or policy risk.
pathway 05MemoryPersistent or session-scoped information that may influence future behavior.
persistent or session-scoped information that may influence future behavior.
unsafe content can be stored as memory, poisoned memory can be reused later, and old context can affect future execution.
Sentinel controls whether memory writes/reads are allowed, flagged, sanitized, or blocked according to policy.
the system has found memory influence or memory storage that may change future behavior in an unsafe way.
pathway 06ApprovalHuman approval, delegated authority, sign-off, or permission escalation.
human approval, delegated authority, sign-off, or permission escalation.
authority can be laundered, reused, misrepresented, or applied to a different action than the one approved.
Sentinel controls whether approval is valid for the requested action, whether escalation is required, and whether the action should pause.
the requested authority may not match the action, actor, context, or policy boundary.
pathway 07Supply chainPlugins, connectors, packages, tools, model assets, or external components the agent relies on.
plugins, connectors, packages, tools, model assets, or external components the agent relies on.
a compromised plugin, unsafe connector, poisoned model asset, or tampered package can influence execution from outside the prompt.
Sentinel controls whether the component, source, or tool path is trusted enough to continue.
the agent may be relying on an unsafe component or untrusted execution dependency.
pathway 08RuntimeLive execution state, service identity, tool sequence, retry behavior, and active run context.
live execution state, service identity, tool sequence, retry behavior, and active run context.
agents can drift, loop, escalate privileges, change service identity, or continue beyond intended limits.
Sentinel controls whether the current runtime behavior still matches the allowed execution envelope.
the run is behaving differently from the expected path, even if a single event looks acceptable.
pathway 09AvailabilityToken usage, retries, load, resource consumption, rate pressure, and expensive execution patterns.
token usage, retries, load, resource consumption, rate pressure, and expensive execution patterns.
runaway loops, cost attacks, token flooding, repeated provider calls, or tool chains can exhaust budget or capacity.
Sentinel controls whether execution should continue, throttle, stop, or escalate based on resource and abuse signals.
the agent may be consuming resources in a way that threatens cost, availability, or service stability.
Twelve surfaces feed one policy context.
A detection is not judged alone.
A prompt event, credential event, retrieval event, tool result, runtime signal, and provider response should not be evaluated as disconnected alerts.
Sentinel maps each surface into the same policy context so decisions can account for route, source, actor, timing, custody, and prior behavior.
That means a low-risk event on one surface can become higher risk when combined with tool lineage, retrieval provenance, credential access, or temporal divergence.
- M01inboundPrompt IntegrityInjection, jailbreak, and instruction-residue detection on inbound prompts.
- M02outboundOutput GovernanceSensitive content, exploit code, and insecure-output containment at the response boundary.
- M03actionsTool-Use GovernanceSanctioned-path enforcement and unbounded-action containment on tool calls.
- M04temporalTrajectory AnalysisCross-turn and cross-session pattern recognition across behavioral chain families.
- M05supplyProvenance AnalysisRetrieval-source integrity, freshness, and supply-chain artifact validation.
- M06baselineBehavioral BaselineService-identity drift, privilege creep, and runtime-state divergence over time.
- M07textText AnalysisNatural-language prompts, completions, retrieval evidence, and tool-call arguments.
- M08ASTCode SafetyGenerated and retrieved code, with structural analysis beyond raw text.
- M09audioAudio GovernanceTranscribed and synthesized audio content.
- M10OCR · metaVision GovernanceEmbedded and generated images, OCR-extracted text, and document metadata screened together.
- M11temporalTemporal AnalysisCross-session recurrence and behavioral patterns over time.
- M12vaultCredential GovernanceCredential routing, token paths, and Vault boundary integrity.
Temporal control maps divergence.
Between intended execution and actual trajectory.
A single event rarely tells the whole story. Sentinel tracks the agent’s path from the originating prompt through tool calls, retrieval events, provider responses, memory writes, approvals, and continuation steps.
The system compares the intended execution path with the trajectory the agent is actually taking. Drift can look harmless one step at a time. Across sequence, it can reveal probing, escalation, evasion, overreach, or compromise.
This is why temporal control matters. A single classifier may see an acceptable request. Sentinel evaluates how the request fits into the broader path.
Tool lineage
Sentinel records which tool call led to which follow-up action, so risk can be traced across the execution tree instead of reviewed as isolated events.
Session continuity
A probe in one turn can matter later. Sentinel keeps mission context connected across turns and sessions so delayed escalation is not treated as a brand-new event.
Ordered chain detection
The same events can mean different things depending on order. Sentinel evaluates whether behavior occurred in a meaningful sequence before escalating or blocking.
Replayable evidence
When Sentinel flags or blocks a chain, the contributing events can be replayed as an evidence sequence: what happened, when it happened, which pathway it used, and which policy applied.
Credentials are execution rights.
Vault keeps raw secrets out of model context.
Agents need to use services, but they should not receive raw API keys, OAuth grants, provider tokens, or sensitive access material as prompt context. Vault separates access from exposure: the agent requests use of a protected capability, and the control path decides whether that use should continue.
Publicly, the important architectural point is simple: credentials are not just data. They are execution rights. Sentinel treats access as an event that can be checked, bounded, recorded, and refused.
Raw secrets stay outside model context.
Vault is designed to keep raw secrets outside model context and to store protected credential material rather than handing plaintext secrets to the model.
Encrypted access boundary.
Vault is designed to protect credential material outside model context. The agent requests use of a protected capability; it does not need plaintext access material in the prompt or provider-bound context. That keeps credential use inside the control path, where access can be checked, bounded, recorded, and refused.
Credential use becomes controlled.
Credential use becomes a controlled event that can be paired with Sentinel policy and approval flows.
Access is checked before continuation.
The agent requests use of a protected capability; the control path decides whether that requested use should continue.
What evidence Sentinel records.
What raw content requires policy.
Sentinel’s default evidence model is metadata-first. It records enough context to prove what happened without making raw conversation content the default retention unit.
Default evidence
Receipt ID, event ID, timestamp, deployment reference, agent/session/run/turn references, pathway, surface, detector/category, severity, confidence, verdict, action, policy version, provider route metadata, latency, payload hash, redaction classes, and audit-chain reference.
Not retained by default
Raw prompts, raw outputs, raw tool output, raw retrieval text, raw provider request bodies, raw provider response bodies, raw credential values, long freeform payload preview, and full payload blobs.
Explicit retention policy
Preview retention, full-payload retention, break-glass retrieval, managed retention, tenant policy, admin acknowledgement, retention period, role, reason code, and audit receipt.
Raw content can still exist in the customer’s own systems, logs, devices, databases, or evidence plane depending on deployment. The default Aera-facing posture is metadata-first unless explicit retention policy enables more.
Where evidence lives.
How custody changes by deployment.
Evidence custody is a deployment choice. The same control path can support local evidence, customer-managed evidence infrastructure, or optional Aera-managed retention depending on the customer’s operational and regulatory requirements.
Local / Desktop Evidence
For solo builders and small teams, evidence can remain on the local device or local Gateway shell. This avoids requiring a server before a team has one.
Customer-Managed Evidence
For enterprise and regulated environments, the customer runs the evidence infrastructure inside their own boundary. The customer controls residency, backup, access, retention, and operational visibility.
Aera-Managed Retention
For teams that want Aera-hosted retention, managed retention can be enabled by tenant policy. Metadata-first evidence remains the default. Preview or full-payload retention requires explicit policy, role, reason, and retention period.
How evidence is reviewed.
Detections, receipts, and replay.
A decision is only useful if the operator can understand why it happened. Sentinel records detections as reviewable evidence: the pathway involved, the surface scanned, the detector that fired, the verdict, the policy reference, and the receipt trail.
The dashboard review model is evidence-first: an operator should be able to inspect what fired, why the control path reacted, and which policy governed continuation.
This illustrative evidence review panel uses generic synthetic labels. It shows the interface pattern for metadata-first detection review without embedding customer data, secrets, raw sensitive prompts, or provider payloads.
Detection record
A detection record explains what fired: pathway, surface, category, detector, severity, confidence, verdict, and policy reference.
Receipt trail
A receipt trail explains why the decision is defensible: event ID, receipt ID, payload hash, timestamp, redaction state, and audit-chain reference.
Replay
Replay reconstructs the sequence that led to a decision so an operator can inspect the path rather than trust a black-box verdict.
Map Sentinel to your agent environment.
If you are routing cloud-hosted agents through third-party providers, Sentinel sits between the agent runtime and provider continuation. If you run local or self-hosted agents, the control path can be placed closer to the customer environment. If you operate in a regulated setting, the evidence plane and retention policy become part of the deployment design.
The next step is not only pricing. It is mapping where Gateway, Vault, Sentinel Edge, evidence custody, and provider routing fit in your environment.