Accountability
The Accountability Layer for Frontier AI
Frontier-class models are now open weights. Capability is becoming free; accountability is not. When a firm brings a model inside its own perimeter, there is no vendor left to point at — everything its agents do is the firm’s to answer for.
The shift
The open-weights wave changes who is answerable
Frontier-class capability now ships as downloadable weights. Moonshot AI publishes open weights for its Kimi K2 series, and has announced K3 with an open-weight release stated to follow. Regulated firms are already pulling models like these inside their own perimeter — often for the most defensible reason there is, which is that they do not want their data leaving it.
But the hosted vendor was doing more than inference. Its logging, its monitoring, its usage policy, its abuse review, its rate limits — a whole governance surface was running quietly on someone else’s infrastructure, and it was doing real compliance work on your behalf. Bring the weights in-house and that layer does not come with them. The model arrives. The accountability apparatus does not.
What follows is the part firms discover late: they have become their own AI vendor, with no upstream. No provider to escalate to, no vendor attestation to attach to a diligence pack, no third party who can be asked what the model did last Tuesday. Regulators attach obligations to use, not to artifacts — so the obligation lands wherever the deployment is, which is now you.
Where we sit
Inside your perimeter, under your agents
When the model, the serving, and the agents are all yours, the accountability layer has to be yours too — and the record it produces has to leave the building without you.
The distinction
Certification is not accountability
They are routinely sold as the same purchase. They answer different questions, at different times, about different things.
Certification
“Was this model safe to deploy?”
- Point-in-time
- About the artifact
- Before the fact
An evaluation, a red-team exercise, a model card, an audit against a standard. Performed once, on a version, before the model ever meets a customer. It is a statement about the artifact — necessary, and finished the moment it is issued.
Accountability
“What did the agent just do, was it permitted, and can you prove it?”
- Continuous
- About behavior
- After the fact, forever
Not a property of the weights but a record of conduct: what an agent did, under whose authority, against which policy — in a form that still stands up when someone disputes it a year later.
Examiners fine conduct, not eval scores.
Which is why these two are complements, not rivals. A certifier’s stamp is a claim made about a model before it is deployed; it needs somewhere to be enforced once the model is doing real work, and somewhere to leave a record when it is not honoured. That is the layer we build. Certify the artifact — then prove the behavior.
Running today
What Rends proves
Everything below describes something running in production today, and every item is stated more fully — with its evidence, and alongside what we deliberately do not claim — on our trust page.
Tamper-evidence the database enforces
Audit records are append-only at the storage layer. A database trigger refuses UPDATE and DELETE on the audit table outright — not a convention the application agrees to follow, an operation the database will not perform.
A hash chain, verified end to end
Every record is hash-chained to the one before it, so altering or removing history breaks the chain in a way verification detects. A gap between what the walker reached and what the table holds is a hard failure, not a pass.
Re-verified nightly, including tenants who have left
A scheduled job re-verifies every chain we hold, every night. It enumerates chains from the audit store itself rather than from the customer list, so the record of a departed tenant keeps being checked rather than quietly dropping out of scope.
Evidence that outlives the tenant that produced it
When an organization is deleted we remove its operational data, but its audit chain is retained under our legitimate interest in preserving a verifiable compliance history. A final entry records the deletion, so the chain says why it ends. Evidence that disappears on account closure is worthless precisely when it is most needed.
Default-deny authorization at the gateway
Authorization at the gateway is default-deny: a request that arrives without a valid organization context is rejected rather than served. Past the gateway, each organization’s data is separated by organization id in application code; the database itself enforces that separation only for API keys, agent action records, policy rules, agents’ spending budgets, the amounts held against them, and the authority granted to agents.
Evidence you can verify without usProfessional plan and above
Export a signed evidence bundle and check it with an open, dependency-free verifier that runs offline. No Rends service, no network, no database — so verification does not depend on our word, our uptime, or our continued existence.
Planned
On the roadmap: model-provenance attestation
We intend that every audit record will carry the model that produced the action — model identifier, weights hash, and serving endpoint — so that “which model did this?” is answered by the record itself rather than reconstructed from deployment history afterwards. In a world where a firm may swap weights on a Friday afternoon, the question stops being rhetorical.
This is not available today. Audit records do not currently carry model provenance. Direction, not a commitment, and no date is promised.
Bringing a model inside your perimeter?
We are onboarding organizations by request, which means a real conversation rather than a signup form.
Request a demo