Access control and audit log: who can change the pipeline, and what they changed
An event pipeline holds the credentials to your warehouse and decides which customer data reaches which tool, so who can change it is a security question. Jitsu answers it with workspace roles, single sign-on, API keys that expire and an audit log that records every change and where it came from.
Workspace roles
Every member of a workspace has one of three roles.
| Role | Can do |
|---|---|
| Owner | Edit and delete configuration, and manage the members of the workspace |
| Editor | Edit and delete configuration |
| Analyst | Read-only access to workspace data, and can trigger sync runs |
An analyst can watch Live Events and check that a sync finished without being able to change a destination or a function.
Single sign-on
The Enterprise plan includes SSO via OIDC, so people sign in to Jitsu through your identity provider, and the sign-in rules you already enforce there apply to Jitsu as well.
An on-premise install connects to your OIDC provider with one setting, AUTH_OIDC_PROVIDER, described in the configuration reference.
API keys and agent connections
Scripts, the jitsu-cli and CI jobs authenticate with a personal API key. Each key has a name and can be given an expiration date, its secret is shown once when the key is created, and it is revoked from the user settings page.
AI agents connect through the MCP server with a browser approval. Each connected client appears in the same list, and revoking it disconnects that client immediately.
The audit log
The audit log records three kinds of event:
- Configuration changes to destinations, streams, functions and connections, with a field-level diff of what changed. Secrets are masked in the diff.
- Membership changes: a member invited, joined, removed or given a different role.
- Logins.
Each record carries its origin: ui, api, cli or mcp. When a function changes on a Friday night, the log shows whether a person changed it in the console, a deploy script pushed it, or an agent rewrote it.
Workspace owners read the log for their workspace in the console, and the same records are available to an agent through the get_audit_log tool, filtered by type, severity, origin and time range. An owner can ask an agent what agents changed last week and get the list.
Controls on changes
Three more controls apply to every way of reaching the pipeline: the console, the Management API, the CLI and the MCP server.
Maintenance mode switches the console API to read-only for an operational window. Tools and requests that change something are rejected until it ends.
The console API is rate limited per minute by default.
MCP tools are labeled as read-only or destructive, so an agent's client can ask for confirmation before update_resource, delete_resource or reset_sync_state runs.
Controls on the data itself
Access control covers the configuration. The event data is controlled in the pipeline, by a function that runs on every event before it reaches a destination. A function drops an event, removes a field, hashes an email or truncates an IP address, so a tool that should never hold a phone number never receives one. The PII masking recipe has the code.
Questions people ask
What roles does Jitsu have? Three per workspace: owner, editor and analyst. Owners manage members, editors change configuration, and analysts have read-only access and can trigger sync runs.
Does Jitsu support SSO? Yes. The Enterprise plan includes SSO via OIDC, and an on-premise install connects to your OIDC provider through the AUTH_OIDC_PROVIDER setting.
What does the Jitsu audit log record? Configuration changes with a field-level diff and secrets masked, membership changes and logins, each with its origin: UI, API, CLI or MCP.
Does the audit log show what an AI agent changed? Yes. Changes made through the MCP server are recorded in the audit log with an MCP origin.
Who can read the audit log? Workspace owners read the log for their own workspace.
Get started with Jitsu
Create a free Jitsu Cloud workspace and invite a teammate as an analyst to see the roles. For SSO, a security review or a deployment inside your own network, see on-premise Jitsu or talk to the team.