Yes. A cloud agent session records prompts, command output, file contents, and sometimes credentials. Sharing the link can expose all of that, depending on visibility settings and repository checks. Review the transcript before sharing, prefer team scoped visibility, and treat anything printed during a session as potentially exposed.
What a transcript can hold
An agent reads files and runs commands, so its record may include source code, error messages with connection strings, environment variable listings, test output, and pasted text. One platform's documentation warns directly: sessions may contain code and credentials from private GitHub repositories, so check a session before sharing.
How sharing options differ
The same documentation describes different visibility models by plan. For team and enterprise accounts, options are private and team, repository access verification is on by default, and the sharer's display name is visible. For individual plans, options are private and public, where public means visible to any signed in user of the service, and repository verification is not on by default. You can require recipients to have repository access and hide your name in settings.
The lesson is general: defaults differ across plans, so check them for your account instead of assuming.
Where leaks come from
| Source | Example |
|---|---|
| Agent printed an environment variable | Token appears in command output |
| Test logs | Connection string in a stack trace |
| Pasted prompt | A developer pasted a key to debug |
| Screenshots or exports | Copied outside the platform's access controls |
| Public or broad link | Anyone with access reads everything |
| Deleted session assumptions | Copies may exist elsewhere |
Reduce the exposure
- Keep sessions private by default, and use team visibility for collaboration.
- Turn on repository access verification where offered.
- Do not put credentials in prompts. Use a proxy or scoped token the agent never reads.
- Tell agents not to print environment variables, and block commands that dump them where your tool allows.
- Review the transcript for sensitive content before sharing outside the team.
- If a secret appears in a session, rotate it. Deleting the session is not enough if others may have seen it.
- Set a retention period that fits your policy, and know what the vendor retains.
Response when a secret shows up
- Revoke or rotate the credential at its source.
- Check provider and service logs for use since the session started.
- Restrict the session link or delete the session, and note who had access.
- Find how it got there, for example a command that printed it, and block that path.
OWASP's secrets guidance supports the rotation approach: rotate regularly so that stolen credentials work only for a short time, and note that restarting an application does not revoke stolen credentials.
Worked example: a share that went too wide
An illustrative scenario. A developer on an individual plan debugs a deployment script with a cloud agent. During the session the agent runs a command that prints the environment, which includes a cloud access key the developer had set for a test. The developer, pleased with the fix, shares the session link in a public channel to show colleagues how it was done.
Anyone with the link and a signed in account on the service can open the transcript. They can read the printed key, the repository path, and the code the agent displayed. Repository verification was not enabled, so access to the repository was not required.
The developer's remediation: revoke the key at the provider, review the provider's access logs, change the session visibility to private, remove the channel message, and set a team rule that sessions are shared at team visibility with repository checks on.
The exposure came from three small choices, none of which looked dangerous at the time.
Pre-share checklist
- Open the transcript and search for key-like strings, tokens, passwords, and connection strings.
- Check commands that printed environment variables or configuration.
- Check pasted text in prompts.
- Check displayed file contents for customer data.
- Confirm visibility, repository verification, and whether your name is shown.
- Consider sharing a summary instead of the whole transcript.
Visibility options compared
| Setting | Who can see | Risk |
|---|---|---|
| Private | You | Lowest |
| Team | Members of your organization | Moderate, scope of the team |
| Public to signed in users | Anyone with an account | High |
| Link with repository verification | Only those with repository access | Lower, depends on how verification is defined |
Names and defaults differ across plans and products, so verify the options in your own account.
Team rules that help
- Default sessions to private or team scoped.
- Require repository verification when sharing.
- Never paste credentials into prompts.
- Block commands that dump the environment where your tool supports it.
- Ask people to share excerpts, not full transcripts, outside the team.
- Train people on the response steps for a leaked secret.
Response steps in order
- Revoke or rotate the credential.
- Check the credential's own audit trail for use since exposure.
- Restrict or delete the shared session, and record who might have viewed it.
- Fix the cause, such as the command that printed the value.
- Record the incident and the fix.
Retention and deletion
Deleting a session removes it from the service according to its documentation, but copies you or others made elsewhere are out of reach. Treat deletion as cleanup, not as a substitute for rotation.
Where Safeguard fits
Safeguard's agent identity and policy features support attributing and controlling agent actions, and compliance and evidence automation can hold your review records.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through it and notice the information shown in each step, then ask who you would be comfortable seeing it if it were shared.
Quick check
Is a private repository enough to keep a shared session safe?
Not by itself. The session can contain code, and the link's visibility decides who sees it. Check repository verification settings.
Does deleting a session fix a leaked key?
No. Rotate the key. Deletion does not undo any copy someone already made.
Is sharing a session within the team always safe?
Safer than public, but teammates may not be cleared for every repository or secret in it. Use repository verification and review the transcript first.
Sources
Last reviewed: 19 October 2026.
