Zero Trust Stops at the Confluence Page

A least-privilege system with a world-readable runbook

The production database accepts connections only from approved workloads. Administrators use MFA. Access is logged. Then a troubleshooting page includes the database URL with credentials embedded, and the Confluence space is readable by every employee.

The network path may follow zero-trust principles; the knowledge path does not.

NIST SP 800-207 says zero trust grants no implicit trust based on network location or asset ownership. Its tenets treat all data sources and computing services as resources, secure all communication regardless of location, and grant access to individual resources per session with least privilege. A credential inside a page is a resource too, even when the page is “internal.”

Page permission and secret permission are different policies

A runbook can be appropriate for hundreds of engineers while its live credential is appropriate for one workload. Embedding the credential collapses those two authorization decisions into the broader one. It also turns page exports, search indexes, browser histories, and support copies into potential credential carriers.

The fix is not simply a smaller space permission. That often destroys the runbook’s operational value and still grants every reader the credential. Keep the procedure broadly available, use a reference or runtime injection for the secret, and make access to the value a separate, auditable decision.

Treat detection as boundary repair

Content scanning is useful because policy will occasionally fail under incident pressure. A stack trace contains a connection string; a responder pastes it at 02:00; the page permission is correct for the discussion but not for the credential hiding inside it.

When that happens, the correct sequence is:

1. redact the exposed representation so it stops spreading;
2. revoke or rotate the credential, because deletion cannot prove it was unread;
3. identify the intended consumers and restore access through a controlled channel;
4. preserve a non-secret incident record for audit and learning.

Secret Sentinel automates the first and fourth parts inside Jira and Confluence: supported secrets are redacted in place and high-risk findings can become tracked Jira incidents. It does not claim to rotate provider credentials; that remains an owner action and should be explicit in the response workflow.

For developer configuration, envseal separates repository membership from secret decryption with per-recipient keys and encrypted values. Together, these controls implement a useful zero-trust invariant: permission to read the surrounding work artifact does not silently become permission to read every operational credential associated with it.

The audit question that exposes the gap

Ask a system owner: “Who can read this page?” Then ask: “Who should be able to use every credential represented on this page?” If the answers differ, the content boundary is wider than the authorization boundary. That is the place to redesign—not after a secret has already become an incident.