Product

Product overview Agents Automations Apps Code (Beta) Integrations Governed Runtime Security

Where Renly runs

Windows app Android app Inside other AI apps

Solutions

Finance Sales Operations People and HR Marketing Enterprise

Resources

Pricing Docs Academy Blog Compare Support

AI governance and capability

AI governance framework AI governance assessment AI capability maturity AI maturity assessment
Book a demo Sign in
Docs / Approvals and governance

Approvals and governance

Renly's rule is simple: agents propose, people decide. Your admins set which actions need approval, and sending, posting, publishing and e-signature requests always need a person. Everything else in the governance stack exists to make that fast, auditable, and impossible to bypass quietly.

Approval cards

When an agent wants to change something outside the chat (creating work items, sending to a connector, editing files in a code session, running a command) and your approval rules call for a person, the action arrives as an approval card:

  • See exactly what will change, field by field or diff by diff, before anything runs.
  • Approve everything, approve a selection, edit the request first, or reject with feedback the agent learns from.
  • Destructive changes require an extra explicit confirmation, and the card cannot be approved by a stray click or keystroke in its first moments on screen.
  • Grant always allow for a specific command or folder when you trust a repeated action, scoped to that chat.

The Evidence Passport

Every response carries a defensible record: the model and provider that served it, the policy verdicts that applied, identity, and the actions taken. Export a passport bundle when work needs to stand up to review, audit, or a client question long after the chat ends.

Fail-closed policy enforcement

On the Enterprise plan, with the Governed Runtime switched on, an independent policy service checks each chat request before it reaches a model, and each automation step and agent hand-off before it runs. When policy says no, the request does not run. If the service cannot be reached, requests are blocked by default; admins can choose to warn or allow instead. Organisation admins also control connector availability, device capabilities, and per-agent tool allowlists.

Privacy in the work log

Tool output shown in the work log masks values that look like credentials, API keys, tokens, and connection strings, so a screen share or screenshot does not leak them. Reveal them explicitly when you need to.

Audit trail

Organisation-level audit logs record sign-ins, configuration changes, approvals, and agent actions on eligible plans. Records created by agents are soft-archived rather than hard-deleted, so mistakes are recoverable.