Security model
Why you can point this at production
Reinventing software you depend on is only worth doing if the reinvention cannot break it. Everything below exists to make that true rather than to sound reassuring.
The premise
The model is an untrusted planner
A language model can propose
delete_customer
with any arguments it likes, for any reason, including one it invented. Caterfli
treats that as a request rather than an instruction, and then decides for itself.
-
01
The tool exists
The name the model produced resolves to a real tool that this agent has been given. A plausible-sounding tool that was never registered fails here.
-
02
Your workspace owns it
The connection behind the tool belongs to this workspace. Tenant scope fails closed — no tenant means no rows, never "no filter, all rows".
-
03
The person holds the permission
An agent acts on somebody’s behalf and can never lend them a capability they do not have. A viewer asking for a deletion is refused here, however the request was worded.
-
04
The arguments validate
Every argument is checked against the schema the connector declared. Types, required fields, enum values and bounds — not a best guess at what the model meant.
-
05
Policy permits it
The operation type and risk level decide what happens next: a read runs, a delete stops. Bulk thresholds and row limits are applied here too.
-
06
A human has approved
When policy requires it, the run pauses. The approval authorises one call with exactly the arguments a person read — re-planning cannot reuse it.
Six checks, none of which trust the previous one’s conclusion. A call that fails any of them is recorded as refused, with the reason, and never reaches your systems.
Approval
What a reviewer actually sees
Not a summary of the intention. The call itself: the tool, its risk level and every argument, exactly as it would be sent. Approving a description of a deletion is not consent to a deletion.
The decision is bound to a fingerprint of those arguments. If the model re-plans and produces a slightly different call, the approval does not carry over — it has to ask again. Approvals expire rather than going stale.
approval
waiting- Tool
- delete_customer
- Operation
- DELETE
- Runs against
- Production PostgreSQL
- Agent
- Support Agent
Exactly these values
{
"customer_reference": "100",
"reason": "duplicate record"
}
Your decision applies to these values only. If anything about the call changes, it stops for approval again.
One call, these arguments, this reviewer. Recorded against the run and kept in the audit chain.
Handling
Your data
It stays where it is
Caterfli holds a connection, not a copy. Answers are live calls to your system, which is why they are never stale and never a second store for you to secure.
Credentials the model never sees
Envelope-encrypted with a key separate from the application key, decrypted only inside the connector to sign a request. Never in a prompt, a response, a log or a browser.
Nothing trains anything
Your data is used to answer your requests. It is not training material — not for us, not for the model provider.
Tenant isolation that fails closed
A global scope every tenant-owned query passes through. If there is no active workspace the answer is no rows, rather than everybody’s.
A tamper-evident audit chain
Every consequential action is hash-linked to the one before it, so a deletion or an edit inside the record is detectable rather than silent.
Outbound requests are guarded
SSRF protection is re-checked on every call, not once at setup, so a hostname that starts resolving to an internal address later is still refused.
Honestly
What we do not claim
An approved deletion is still a deletion
The change log tells you what happened, when, and who agreed to it. It does not put the row back. Keep your backups.
We cannot audit your own systems
Caterfli records what it did. What else has access to that database, and what it did, is outside anything we can see.
A model can still be wrong
The checks constrain what a wrong plan can do; they cannot make the plan right. That is exactly why destructive work waits for a person.
Permissions are yours to get right
The credential you supply is the ceiling. If it can drop tables, the ceiling is dropping tables — give it the narrowest grant that works.
Found something we should know about?
Tell us before disclosing publicly. We will confirm receipt and keep you updated through the fix.