Provenance as a first-class tag
USER_INPUT, UNTRUSTED_CONTEXT and SYSTEM labels travel with the content, so a rule can treat an instruction from the user and one scraped from a web page as fundamentally different things.
The Vault Gate · room 04 of 11
SentinelLLM
Your LLM can make decisions. It shouldn't get unrestricted access.
SentinelLLM is a defence-in-depth security gateway for LLM applications: content entering the runtime carries provenance tags, detection is probabilistic, and the actions that actually execute are governed by a deterministic, separately-auditable enforcement path.
It exists because an LLM that can make decisions should never also hold unrestricted keys — judgement and permission are different mechanisms, and this project gives each its own.
a request, gated — provenance in, audited action out
untrusted requestdetectionpolicy decisionenforcement gateaudited action
approved → SHA-256 digest matches, token unused → executes once
unapproved → gate blocks → audit trail records the attempt
The actual problem
In a typical LLM application, one component both decides and acts: the model's output flows straight into tools, databases and external calls. A single prompt injection, or one confident hallucination, therefore becomes an unauthorised action.
The hard requirement is separation without paralysis: content must carry provenance (who wrote it — user, untrusted context, or system), suspicious content must be detected probabilistically, but the decision to actually execute must be deterministic, permissioned and auditable after the fact.
The exploded machine
Everything entering the runtime is stamped with provenance — USER_INPUT, UNTRUSTED_CONTEXT or SYSTEM — so downstream policy can reason about origin, not just content.
Intake sorter — every request enters the same way
One intake path for everything — no side doors, so nothing skips the gate.Provenance stamper — USER_INPUT · UNTRUSTED_CONTEXT · SYSTEM
Content carries its origin as a tag; downstream policy reasons about origin, not just payload.Detection sieve — probabilistic
Suspicious content is flagged statistically — and can never execute anything on its own.Enforcement gate — PDP / PEP, deterministic
The Policy Decision Point decides; the Policy Enforcement Point executes. Detection and enforcement are decoupled — a missed detection cannot directly become an action.Approval desk — SHA-256 digests, single-use tokens
Sensitive actions require human approval bound to the exact payload — approving once cannot be replayed.PostgreSQL lock drawer — row-level locking
Concurrent requests race for the same approval; the database serialises them so the guarantee holds under load.Audit reel — full trail, credential redaction
What actually happened is recorded — with credentials redacted — so the gate stays auditable after the fact.
A probabilistic detection layer flags suspicious content, but it can never execute anything: policy decisions (PDP) and action enforcement (PEP) are decoupled, and enforcement is deterministic — an action runs only when policy says so.
Sensitive actions require cryptographically bound human approvals: SHA-256 argument digests and single-use tokens mean an approval applies to exactly one payload exactly once. PostgreSQL row-level locking prevents race conditions around that guarantee, and a full audit trail with credential redaction records what actually happened.
Engineering decisions
Detection and enforcement are different layers
A probabilistic classifier may be wrong; a policy gate must not be. Keeping them decoupled means a detection miss can never directly become an executed action.
Approvals bound to payloads
SHA-256 argument digests plus single-use tokens make an approval unforgeable and unrepeatable — approving 'delete record X' cannot be replayed as 'delete record Y'.
PostgreSQL row-level locking
Concurrent requests racing for the same approval or action are serialised at the database, so the guarantee holds under load, not just in a single-threaded demo.
Proof — verified results
- PromptProbe suite
- 23 test cases + 10 multi-step scenariossynthetic fixtures
- PromptProbe overall accuracy
- 95.6%synthetic fixtures
- Unauthorised simulated tool executions
- zerosynthetic fixtures
- Backend tests
- 264repo
- Frontend tests
- 16repo
- Dashboard
- Next.js 15 security-ops consolerepo
every number here carries its source — my resume's figures and the synthetic-fixture results are marked for what they are