Why agents need audit logs, scopes, and shared workspace data

Most agent demos run inside a sandbox with a synthetic database, end with a screenshot of a green checkmark, and never touch a real business. The interesting problem starts the moment an agent has to read and write real records that humans also read and write.

Three things make that safe enough to deploy: audit logs, explicit scopes, and shared workspace data.

Audit logs

If an agent edits a deal, closes a ticket, or publishes a CMS entry, you need a permanent record of what happened, when, and on whose behalf. The audit log is what lets you trust the agent in production — not because it never makes mistakes, but because you can find the mistakes after the fact and undo them.

Explicit scopes

Every credential — API key, MCP client, OAuth grant — carries a set of scopes. Scopes are coarse-grained at module level (crm:read) and fine-grained at action level (support:write:comments separate from support:write:messages). A prompt is not access control. A scope is.

Shared workspace data

If the agent reads from a vector store while the app reads from a database, the agent's reality and your reality diverge the moment any record changes. Both should read and write the same business objects, in the same workspace, with the same constraints. That is the model Slab5 ships with.

What this looks like in practice

A scoped agent inside a Slab5 workspace can do real work: triage support tickets, draft CMS revisions, schedule follow-up tasks, dedupe leads. Each action is auditable, each credential is revocable, and the agent is operating on the same records as the rest of the business — not a copy.

Treat each agent as a workspace-scoped credential with explicit scopes. Read the audit log periodically. Revoke when behavior drifts.

Audit events accompany every important REST and MCP write. Webhook endpoints can mirror audit events into your security stack.