Product / Trust & Audit
Every action scoped, logged and attributable
A disputed case has to be reconstructible months later. Ruhu keeps a tamper-evident log of every sign-in, configuration change, administrative action, tool authorisation decision and credential read, chained by hash so you can filter it, export it and verify it.
Audit Logs
Tamper-evident log of every state change, sign-in, and administrative action, chained by hash so it can be verified.
Activity overview
30 Aug 2026 – 28 Sep 2026
Total Events
12,480
Success Rate
98.7%
Outcomes
success: 12,318, denied: 121, failure: 41
Event Types Tracked
9
Most Frequent Events
Event timeline
12,480 events
| When | Event | Outcome | ||||
|---|---|---|---|---|---|---|
Sep 28 09:14:02 | updateUpdated PUT /api/agents/ag_7f21c0a9/draft | 4f9c2e1a08b3 102.89.4.17 | agent ag_7f21c0a9 | success | 84ms | view |
Sep 28 09:12:40 | securityPermission denied POST /api/tools/definitions | 9a0b7d3e55c1 41.58.190.2 | tool_definition | denied | 3ms | view |
Sep 28 08:57:11 | authLogin POST /auth/magic-link | 4f9c2e1a08b3 102.89.4.17 | --- | success | 212ms | |
Sep 28 08:41:05 | createCreated POST /api/policies | 7c1d9f0b2a64 102.89.4.17 | policy pol_3b8e17d2 | success | 61ms | view |
Sep 27 22:03:48 | updateSettings changed PUT /api/settings/tool-authorization | 7c1d9f0b2a64 102.89.4.17 | organization org_acme | success | 47ms | view |
A log you can verify
Every sign-in, change, admin action, tool authorisation decision and credential read, chained by hash.
Filter by event type, outcome and resource over 7, 30 or 90 days, with the activity overview above the timeline, and export it as CSV.
Every event is linked to the one before it. The verification endpoint walks the chain and reports whether it holds.
Audit Logs
Tamper-evident log of every state change, sign-in, and administrative action, chained by hash so it can be verified.
Activity overview
30 Aug 2026 – 28 Sep 2026
Total Events
12,480
Success Rate
98.7%
Outcomes
success: 12,318, denied: 121, failure: 41
Event Types Tracked
9
Most Frequent Events
Event timeline
12,480 events
| When | Event | Outcome | ||||
|---|---|---|---|---|---|---|
Sep 28 09:14:02 | updateUpdated PUT /api/agents/ag_7f21c0a9/draft | 4f9c2e1a08b3 102.89.4.17 | agent ag_7f21c0a9 | success | 84ms | view |
Sep 28 09:12:40 | securityPermission denied POST /api/tools/definitions | 9a0b7d3e55c1 41.58.190.2 | tool_definition | denied | 3ms | view |
Sep 28 08:57:11 | authLogin POST /auth/magic-link | 4f9c2e1a08b3 102.89.4.17 | --- | success | 212ms | |
Sep 28 08:41:05 | createCreated POST /api/policies | 7c1d9f0b2a64 102.89.4.17 | policy pol_3b8e17d2 | success | 61ms | view |
Sep 27 22:03:48 | updateSettings changed PUT /api/settings/tool-authorization | 7c1d9f0b2a64 102.89.4.17 | organization org_acme | success | 47ms | view |
Who can do what
Identity comes from your provider, roles are ranked, and row-level security in the database keeps every query inside one tenant.
OIDC sign-in with groups mapped to viewer, analyst, developer, admin or owner, and SCIM 2.0 keeping membership current.
Off, Log only or Enforce, with a 14-day observation window and a readiness check before enforcement.
Team Members
Roles come from your identity provider’s groups, or are set by hand.
| Name | Role | Source | Status |
|---|---|---|---|
| Ada Okafor | owner | manual | Active |
| Ijeoma Bello | admin | sso_group_mapping | Active |
| Tunde Adeyemi | developer | sso_group_mapping | Active |
| Chiamaka Eze | analyst | sso_group_mapping | Active |
| Samuel Mensah | viewer | sso_group_mapping | Invited |
SCIM 2.0 · provisioning and de-provisioning from your directory
Personal data stays yours
Detection and redaction, credentials encrypted at rest, and a tracked process for every data-subject request.
Google DLP and Presidio find phone numbers, emails and other identifiers in text and redact them.
Connection secrets are encrypted at rest with AES-256-GCM, keyed from a ring so keys can rotate, and every read is an audit event.
Export, correct or delete a customer’s data on request, tracked from receipt through identity verification.
Personal data
Detection and redaction with Google DLP and Presidio.
Customer, 09:14:20
My number is [PHONE_NUMBER] and you can reach me at [EMAIL_ADDRESS] about the roaming charge.
- PHONE_NUMBERPresidio0.99
- EMAIL_ADDRESSGoogle DLPLIKELY
Trust & Audit by the numbers
Hash-chained
Every event linked to the one before it, with a verification endpoint
5 roles
Viewer to owner, ranked so an identity-provider mapping typo can never escalate
Row-level
Tenant isolation enforced by the database, not the application
How it works
Up and running in three steps
01
Sign in through your identity provider
Ruhu sets up OIDC for your tenant, maps your groups to roles and keeps membership current through SCIM 2.0.
02
Set the controls
Choose the tool authorisation mode in Settings and follow enforcement readiness until Enforce is safe to switch on.
03
Verify and export
Filter the audit log by event, outcome and resource, export it as CSV, and verify the chain through the API whenever an auditor asks.
FAQ
Common questions
Which certifications do you hold?
None yet. We publish the controls we have implemented rather than badges, and we will say so plainly when a SOC 2 or ISO 27001 audit completes.
Who can see what?
Five ranked roles: viewer, analyst, developer, admin and owner. Admins and the account owner manage the organisation. Roles come from your identity provider's groups or are set by hand, and every role is scoped to one tenant.
Where is data stored?
Ruhu runs on Google Cloud, AWS or Microsoft Azure, in our account or yours. Talk to us about the region your regulator requires before you sign.
Can we run it in our own environment?
Yes. The platform is containerised and deploys into your own AWS, Google Cloud or Microsoft Azure account. Talk to us about what your team would operate.
Start with one workflow
Which customer request should we tackle first?
Bring a procedure and the systems it touches. We’ll walk through the agent, the setup and how you would measure the result.