1
Export the bundle
Organisation settings writes out the sealed records with their digests, chain positions, and links, as a file you keep.
Governed Runtime
Other platforms log what the AI did. Renly hands you proof.
Every governed action is sealed into a signed record and linked into a hash chain, so you can export the evidence and check it yourself.
The artefact
One action, one record
An audit log tells you something happened. This is a structured document naming the person, the agent, the model that actually served the request, the policy decision, the human who approved it, and every side effect, sealed so later edits are detectable.
Evidence record
corr_7f21c9a4e8b3
Cryptographically sealed (HMAC-SHA256)
sha256: 4c1f8b0a97d2e6135ba0c8f47e91d3aa2c65b8104fd7e39c
Action
- Kind
- tool_call
- At
- 9 Sep 2026, 14:22:07 AEST
Identity
- User
- usr_1042
- Workspace
- ws_finance
- Session
- ses_88ac1f
Model
- Requested
- claude-opus-5
- Resolved
- claude-opus-5
- Provider
- anthropic
Verdict
- Gate
- approved
- Policy
- allow
- Evaluator
- structural, semantic
- Confidence
- 0.94
Governance passport
- Policy ref
- pol_outbound_email
- Policy version
- 3
- Prompt hash
- 8ae0d41c7b92f5e0
Tools (1)
succeeded
outlook.send_email
write
approved by usr_1042
Chain
- Sequence
- 4,182
- Previous
- 9f3ac70e5d18b4426a0f
Sample record with representative values. The sections and field names are the ones Renly writes.
Seven questions, answered by construction
Auditors and incident reviewers ask the same things every time. Renly writes the answers at the moment of the action rather than reconstructing them later from logs.
- Who asked. The user, workspace, and session, including the administrator if the session was impersonated.
- Which agent acted, at which version, so behaviour can be traced to a specific configuration.
- Which model actually ran. Requested and resolved are both recorded, because routing and fallbacks mean they differ.
- What policy decided, at which policy version, with the evaluator and its confidence.
- Who approved what, bound to a digest of the exact proposal rather than a general permission.
- What changed in the outside world. Each tool call, whether it was side effecting, and where the result landed.
- Whether the record is intact, from its own digest and its position in the chain.
Tamper evidence
The records are chained, so silence is detectable
A record that can be quietly edited or deleted is not evidence. Each sealed record carries the digest of the one before it, so altering or removing any record breaks every link that follows it. You do not have to take our word that nothing was changed, the arithmetic settles it.
Independent verification
Check the evidence without trusting Renly
Governance you can only confirm by asking the vendor is not governance. The format, the canonicalisation, and the algorithm are published, so your own team or your auditor can run the check.
2
Recompute the digests
Canonical JSON with sorted keys, SHA-256 for content, keyed MAC for the seal. The reference implementation is Apache-2.0 and has no dependencies.
3
Find the break, if there is one
Verification returns the count of intact records, or the first sequence number where the chain stops holding. There is no partial credit.
Approval
An approval that cannot be reused for something else
Most approval flows record that a person clicked yes. Renly binds the approval to a digest of the exact proposal, with a scope and an expiry. If anything about the action changes between the approval and the execution, coverage fails and the action does not run.
Executed as approved
The user approved sending an invoice reminder to a named recipient. At execution the arguments hash to the same digest that was approved.
covered: true
Recipient changed after approval
Same tool, same session, one field different. The digest no longer matches the approved proposal, so the gate refuses it rather than assuming consent carried over.
covered: false, reason args_mismatch
Standing approvals carry a match rule, an expiry, a use count, and a revocation, so authority that quietly widens over time is visible rather than assumed. The rules are written up in the Action Approval Attestation.
When something is wrong
If it cannot be recorded, it does not run
The failure mode of most AI governance is quiet degradation: the checking layer goes down and the requests sail through unchecked. Renly treats an unavailable evidence pipeline as a reason to stop.
Evidence mandatory
A use case can be flagged so that side effecting actions are blocked whenever the evidence pipeline cannot sign, whatever the enforcement mode says.
Structural gates fail closed
Approval gates and write controls block rather than bypass when they cannot evaluate. This holds on every plan.
Low confidence escalates
When semantic evaluation is not confident enough, the request goes to a human reviewer instead of resolving itself in the agent's favour.
Autonomy has a ceiling
Each organisation sets the highest autonomy any agent may reach, from observe through suggest and approve to auto. An agent cannot exceed the ceiling by asking.
Model governance
Which providers and tiers may serve requests is an organisation setting, and the model that actually answered is recorded, not assumed.
Organisation scoped isolation
Policies, evaluations, evidence, and chains are scoped to one organisation. Each organisation has its own chain, starting from its own genesis.
In the product
Where your team operates it
Policies, approvals, and the evidence chain sit in organisation settings, with verification and export as buttons rather than a support request.
Evidence records
Every governed AI action is captured as a signed attestation and linked into a per-organisation SHA-256 hash chain.
Verify chain
Export bundle
Integrity verified, 4,182 of 4,182 sealed records intact, chain unbroken.
| Action | Gate | Model | Seq | Digest |
|---|---|---|---|---|
| outlook.send_email | approved | claude-opus-5 | 4,182 | 4c1f8b0a… |
| jira.create_issue | approved | claude-opus-5 | 4,181 | b1087a2d… |
| sharepoint.write_file | escalated | gpt-5 | 4,180 | 2e77df41… |
| d365.update_record | blocked | claude-opus-5 | 4,179 | 7a30c9b6… |
Illustration of the governance area in organisation settings. Values are representative.
What you get where
Available now, and what Enterprise adds
Attribution, approval gates, and the sealed audit trail are not an upsell. They are how the runtime works on every plan.
Attribution
Every action tied to a user, agent, and the model that actually served it.
Every plan
Approval gates
Writes to connected systems pause for review, bound to the exact proposal.
Every plan
Sealed evidence chain
Signed records, per-organisation hash chain, verification and export.
Every plan
Identity
Entra ID single sign-on and role scoped access.
Every plan
Semantic evaluation
Contextual policy assessment alongside the structural rules, failing closed.
Enterprise
Extended policy layers
Additional enforcement points for higher risk environments.
Enterprise
Investigation workflows
Deeper evidence tooling for incident response and regulator requests.
Enterprise
The standard
We published the bar we hold ourselves to
Governed is an unregulated word, so we wrote down what it has to mean and made the specifications open under Apache-2.0, with a reference implementation and a conformance suite. Renly states Level 3 conformance to all three, using a keyed MAC rather than public key signatures.
Action Provenance Record
action-provenance/1.0
What the agent did, for whom, with which model, and what happened.
Action Approval Attestation
action-approval/1.0
What exactly a human permitted, for how long, and how to prove it.
Governed Runtime Profile
governed-runtime/1.0
Twelve testable guarantees a runtime must meet to call itself governed.
Ask any vendor to export an action and prove it was not edited
It is a fair question, and it is the one Renly is built to answer. Attribution, approval gates, and the sealed chain are there from your first login. Bring us the evidence question your auditor or your board is asking.
Talk to Sales Read the Governed Runtime Profile