Neltava sits between an agent and money, so its own failures matter as much as the agent’s. This page says what we do, plainly, and what we don’t claim.
How decisions stay safe
- Your rules decide. Budgets, limits, merchants, categories and pace are checked deterministically, in a fixed order, and every step is returned in the decision’s trace.
- An AI judgment never blocks on its own. The purpose assessment can only send a spend to a person. A failed or unavailable assessment also goes to a person — never to an automatic allow.
- No fail-open where decisions take effect. If Neltava can’t be reached, the SDK and MCP server don’t let an enforced agent spend: “allow when unavailable” works only while an agent is confirmed in Shadow Mode, and never on a rate limit.
- One decision, one spend. Retries return the same decision (idempotency keys); a decision is bound to the authority version it was made under, and an approval is refused if the agent was paused or its authority changed since.
- Budgets reflect reality. An allowed amount stays reserved until the window ends. An agent saying “it failed” never gives budget back; only the payment rail’s own report does.
Enforce at the payment point
In Enforce, every allowed spend carries a capability: a short-lived, single-use token signed with Ed25519 and bound to the workspace, agent, decision, authority version, payee, amount ceiling, currency and action. Your payment service consumes it right before paying; it can’t be reused, raised or redirected. The public keys are at /.well-known/neltava-jwks.json. See Enforce at the payment point.
Prompt injection
- What an agent sends — its task, steps, merchant and description — is evidence, never instructions.
- Text that addresses the judge (“ignore previous limits”, “pre-approved by the owner”) is detected and turns an aligned assessment into uncertain, so a person decides.
- In the MCP server, request text is quoted and kept off the verdict lines, so a merchant name can’t forge a PROCEED. See prompt injection.
Keys and access
- API keys are stored only as SHA-256 hashes and shown once.
- Keys are scoped: an agent’s key can only ask for decisions as that agent; reviewers, read-only tools and payment adapters each get their own. Keys and scopes.
- Everything is isolated per workspace; every lookup is made inside the caller’s workspace.
- The person who asked for a spend can never review it.
- Requests are rate-limited per key; failed authentication is limited per client.
- Tokens Neltava holds for you (such as a Slack connection) are encrypted at rest with AES-256-GCM and never returned by the API.
A tamper-evident history
Decisions, reviews, labels, outcomes and capability use are append-only and chained with SHA-256, per workspace. GET /v1/ledger/verify re-derives the chain from the stored records and reports any edit. Tamper-evident, not tamper-proof: an edit can’t go unnoticed.
Your data
- Everything is encrypted in transit (TLS 1.3).
- We don’t sell your data, and we don’t use your workspace or decision data to train AI models.
- The API request log keeps metadata only — never bodies — for 7 days.
- Webhooks are signed (HMAC-SHA256) and go only to public HTTPS addresses; redirects aren’t followed.
- A small number of service providers run the service (hosting, database, email, payments, AI model access). The details are in the privacy policy.
How we test it
Before launch we ran an internal adversarial review of the product — cross-tenant access, privilege escalation, prompt injection into payments, replay, race conditions and budget double-spend, webhook forgery, SSRF, rate-limit bypass and fail-open behaviour — and closed every high and critical finding. Each exploit attempt is kept as an automated test that runs on every change.
Report a vulnerability
Write to hello@neltava.com with “Security” in the subject. Tell us what you found and how to reproduce it; please don’t access other customers’ data or disrupt the service while testing. We’ll get back to you as soon as possible and keep you posted until it’s fixed.