Skip to main content
Session content is the prompts, responses, tool inputs and tool outputs of a session, and the titles and topics made from them. These controls decide who can read the content of other people’s sessions.
Session content access is enabled per organization on request. Contact your Runlayer account team to enable it.

​
What stays visible

Metadata always stays visible: times, event types, tool names, model, tokens and cost. When you can’t read a session’s content:
  • Lists and search show ***REDACTED*** in place of the title, topic and first prompt. Search doesn’t match the hidden content.
  • The session panel shows Withheld by policy or Protected session instead of the conversation.

​
Who can read content

You can read a session’s content when one of these is true:
  • You own the session. The owner of an agent run is the person who started it.
  • The owner shared the session with you.
  • A policy gives you access.
  • You have approved break-glass access.

​
Explicit content grants

By default, admins with the View unredacted content capability can read everyone’s content, as before. To change that:
  1. Go to Settings → Agent session monitoring.
  2. Turn on Explicit content grants and save.
Now admins, Super Admins included, no longer read other users’ content by default. They need a policy or approved break-glass access.

​
Grant access with a policy

  1. Go to Settings → Policies and create a policy.
  2. Under Targets, pick Sessions.
  3. Pick All sessions, or Sessions where and set any of these:
    • Group: the session owner’s group, synced from your identity provider.
    • Client: the app the session ran in, such as Cursor or Claude Code.
    • Connector: a connector the session used.
  4. Pick the people, groups or roles that get the action Read content, and save.
Every field you set must match. Each field takes one value, so add one policy per client. For example, to let the Platform group read Cursor and Claude Code sessions, add two policies for that group: one with Client set to Cursor, one with Claude Code.

​
View all runs on an agent

A policy that grants View all runs on an agent also opens the content of that agent’s runs. People with this grant find the runs on the agent’s Sessions tab. See Who can see an agent’s runs. With explicit content grants on, only a View all runs policy opens other people’s runs. Owning the agent does not.

​
Break-glass access

Break-glass gives one person access to one session for a short time. A second Super Admin must approve it. These roles can ask: Super Admin, Security Admin, IT Admin, Helpdesk and Analytics Admin. Only a Super Admin can approve, and nobody can approve their own request.
  1. Open the session and click Request access.
  2. Enter a reason (up to 255 characters).
  3. Pick how long you need access: 1 hour by default, 4 hours at most.
  4. Click Request access.
Another Super Admin approves it in the approvals inbox or on Slack. The time starts when they approve. A request nobody decides expires after 24 hours, and you can withdraw it before then. Access ends when:
  • The time is up.
  • You click End access on the session.
  • A Super Admin revokes it under Settings → Agent session monitoring → Break-glass access. This card lists everyone who has access now.
  • The requester or the approver is deactivated.
Each person can ask 10 times an hour, and the organization 30 times an hour.

​
Protected sessions

Protect the sessions of a group, for example HR, legal or executives. Only the session’s owner and break-glass access can open a protected session. Roles, policies and shares do not, and Runlayer refuses new shares of protected sessions.
  1. Go to Settings → Agent session monitoring → Protected sessions.
  2. Pick a group synced from your identity provider and click Protect.
  3. Another admin with Manage security policies approves the change in the approvals inbox or on Slack.
Removing a group needs a second admin too. You can withdraw your own pending change. Sessions that use a Sensitive Connector are protected the same way, without a group.

​
Audit log and Security Signals

The audit log records each break-glass request, approval, denial, revoke and read, and each protected-session change. These raise a Security Signal in Incidents:

​
Limits

  • Break-glass needs two Super Admins. With only one, the request fails with “Nobody else can approve. Add a second Super Admin.”
  • Groups must come from your identity provider. Session policies and protected sessions only take directory-synced groups. Runlayer refuses a group made in Runlayer.
  • Grants don’t add sessions to anyone’s list. A policy or break-glass opens content in sessions you can already see. It does not add sessions to your Sessions page. To let a team see an agent’s runs, grant View all runs on the agent.
  • Session policies only allow. Runlayer refuses a deny by group, client or connector, and session policies take no conditions.
  • The session SIEM export is not filtered. It still contains all content. See SIEM export.
  • One Super Admin can turn off Sensitive Connector. That removes the protection of its sessions without a second admin. It raises a Security Signal.