Overview
Thulpar is an on-prem security and guardrails layer for AI agents and LLM applications: a policy decision point, replaceable detectors, a hash-chained evidence ledger and an approval inbox; not a byte leaves at run time.
Updated: October 2026What Thulpar is
Thulpar is a policy decision point installed in front of your models, tools and agents. Every stage of an agent run passes through it; the policy pack says which rails run, rails bind to detectors or built-in checks, the decision returns to the caller and the event is written to the tenant’s hash chain.
It is not a classifier API. The decision comes from policy, not from the model; an action above the threshold lands on a person; every decision binds to a policy version and every finding to a control id. The product runs in the organisation’s own data centre, on a closed network or on Kubernetes; there is no telemetry, no licence ping and no remote generation.
The problem
Agents no longer just talk; they transfer money, open work orders, read files, swap SIMs. Content filters written for chatbots are not enough in that world. Four requirements arrive together:
- An action, not a message
- A tool call cannot be undone. The decision has to come from policy, not the model, and pass a person above the threshold.
- Indirect injection
- The attack is not in the prompt; it arrives in the e-mail, the PDF and the tool output the agent reads. Everything read must be labelled untrusted.
- The evidence duty
- BDDK, KVKK, the EU AI Act: which policy version, which detector, which decision? Not a log line; a signed chain.
- The closed-circuit requirement
- Defence, government, banks: prompts and answers cannot leave. Neither may the guardrail, licence ping included.
Three pillars
- Policy decision point
- The rails’ mode (enforce, shadow, audit), posture (closed, open), threshold and deadline are written in the policy pack. Packs layer through org → tenant → app → agent inheritance, are signed and versioned; tool calls are authorised with Cedar; information-flow labels are enforced at sensitive sinks.
- Replaceable detectors
- Injection, jailbreak, PII (TCKN and IBAN with checksums), health data, toxicity, content safety, groundedness, code, files, images, YARA; one HTTP contract. The CPU tier runs production without a GPU; the GPU tiers add guard LLMs over vLLM. A rail binds to a detector by meaning, not by name.
- Evidence ledger and approval inbox
- Every decision is appended to a SHA-256 chain: policy version, detector versions, findings, latency, a redacted sample. Daily anchors, nightly verification, signed evidence packs in seven regulator profiles. A hold lands in the approval inbox: four eyes, SLA, escalation, webhooks; on approval the run resumes where it paused.
Four surfaces
Thulpar is reached four ways; the policy, the ledger and the console are the same on all of them. What changes in the application is usually just a base URL and a tenant-bound thp_live_… key.
| Surface | What it does | Who uses it |
|---|---|---|
| OpenAI-compatible gateway | Goes in front of the model: /v1/chat/completions, /v1/completions, /v1/responses, /v1/embeddings. The input stage before the first upstream byte, the output stage sentence by sentence, in-band retraction on streams. | Existing OpenAI clients; teams that want no code change |
| MCP proxy | /mcp/:server goes in front of tool servers: schema pinning, quarantine, description hygiene; tools/call arguments pass Cedar, the schema and the injection rail. | Agents with an MCP client |
| Check API | POST /v1/check from inside your own application at every stage; streaming, speculative tickets, what enforce would have said in shadow. | Teams writing their own agent framework; the Python SDK |
| Embedded in Aginies | The Platform, Hub, Dialog, Voice and Code adapters call the check API from the executor hooks; a hold lands on the Platform’s approval card. | Organisations on the Aginies Platform |
Who it is for
Banks, insurers, defence and the public sector in Türkiye first; then telecom, healthcare, energy, retail, logistics, manufacturing, robotics and software. Every sector has a signed policy template and an evidence profile: BDDK banking, SEDDK insurance, public sector, defence, EU AI Act high risk.
| Profile | Install | Identity | Licence |
|---|---|---|---|
| Standalone | The thulpar installer: a per-customer registry token or the air-gap bundle; the first-run wizard | The organisation’s OIDC provider; local admins + TOTP without an IdP and as break-glass | A signed licence file uploaded in the console |
| Aginies-embedded | With the Aginies deployment; the adapters on | Platform SSO; a local admin only as break-glass | The same licence file, in Thulpar’s console; verification, enforcement and metering always in Thulpar |
Not in scope
Thulpar protects applications and agents, not employees’ browsers. Saying what it is not matters as much as saying what it is:
- Not a browser extension or a workforce SaaS-usage control; it does not watch employees’ ChatGPT use.
- Not a model inventory or a cloud posture-management platform; it decides at run time.
- Not an LLM gateway or cost manager; the gateway is one surface of the decision engine.
- Not a model; it runs guard models as replaceable detectors and mandates no vendor model.
- Not open source; customers can obtain source access by contract and an escrow arrangement.
Glossary
| Term | Meaning |
|---|---|
| stage | Where the content sits in the agent loop (input, output, output_chunk, retrieval, tool_call, tool_result, memory_write, agent_trace, file). |
| rail | One check at a stage, declared with its detector class, minimum grade, mode, posture, thresholds and deadline. |
| decision | allow, allow_with_findings, redact, rewrite, prepend, deny, hold, escalate; the strongest wins. |
| mode | enforce (the decision is applied), shadow (recorded, never blocked), audit (asynchronous, 202), off. |
| posture | What happens when a rail cannot run; closed → the check is denied, open → it passes; a ledger event either way. |
| pack | Policy pack: rails, tool groups, sink classes, Cedar policies, approval profiles, retention and evidence profiles; signed, versioned JSON. |
| tenant | An organisation or business unit with its own policy pack, ledger chain, API keys and approval inbox. |
| finding | A rail’s detection: category, score, severity, spans, detector and version, control id. |
| ledger | The evidence ledger: a SHA-256 hash chain per tenant; hashes are stored, never content. |
| anchor | The root hash of the events since the last anchor; written daily, exportable to an external notary or SIEM. |
| evidence pack | A signed ZIP per tenant, period and regulator profile; verified offline. |
| hold | The decision that opens an approval record; the caller waits or resumes after approval. |
| sink | A tool’s sensitive output class (egress, messaging, export, write, exec); labels are enforced here. |
| label | Integrity (trusted/untrusted), confidentiality (public … pii), PII classes and source travelling with the content; labels only go up. |
| tier | Hardware class (Starter, Standard, Recommended, Performance); it only decides which detectors are installed. |
| detector class | The meaning a rail needs (injection, pii, content_safety, groundedness, file, …); a rail picks its detector by class. |
| grade | The detector’s measured quality class (A, B, C); a rail declares its minimum. |