Skip to main content
Guardrails decides which sensitive values agents never see in the clear. When a protected value shows up in what an agent works with, such as a customer email in a log line, the agent reads a placeholder instead. You manage it in Admin Settings → Guardrails: turn built-in identifiers on or off, and add patterns for ID formats only your team uses.

​
Prerequisites

  • The Admin role in the workspace, to change settings for that workspace.
  • The organization Owner or Admin role, to set the organization baseline, lock a rule, or move a pattern to the organization.
  • A regular expression for any custom ID format you want to hide. You don’t need sample values.

​
What agents see

Each row in the table is a built-in identifier or a custom pattern. Click a built-in row to see its description and an example of what the agent sees. Defaults that are on start at the Organization scope. A few details from the built-in rules:
  • Email skips addresses at the reserved example.com, example.net, and example.org domains. Phone skips the reserved 555-0100 to 555-0199 range.
  • Credit card and IBAN only match numbers that pass their checksum, so random digit strings stay visible.
  • API keys and Cloud credentials are secret protections, not PII. Cloud credentials covers secret keys and service account keys for AWS, Azure, Google Cloud, and more. A bare AKIA… key ID stays visible. Lock both rows at the organization so no workspace turns them off.
A placeholder can’t be turned back into the value, so an agent can’t search by a masked value, for example look up a user by email. Only mask what agents never need to query on. That’s why IP addresses and Cloud account IDs start off: agents investigating network or IAM issues often need to read them.
A change applies to tool output from then on. Output already stored keeps the placeholders it had, and turning a rule on doesn’t mask values already shown.

​
Set where a protection runs

The Scope column has three positions for every row. Who clicks decides how far a change reaches. For a built-in rule at Organization: A locked rule doesn’t move for anyone until an organization Admin unlocks it.
1

Open Guardrails

Go to Admin Settings → Guardrails. Use Search identifiers, or filter by scope and by type (Built-in or Custom).
2

Pick a scope

Click Off, Workspace, or Organization on the row. The change saves on click. There’s no Save bar.Success state: the row shows the new scope.
3

Lock it (optional, organization Admins)

Set the row to Organization first; the padlock is only active there. Then click the padlock in the Actions column to keep the built-in rule on for every workspace.Success state: workspace Admins can no longer turn the rule Off. Click the padlock again to unlock it.
A workspace Admin can turn off an organization rule for their workspace only while it’s unlocked. Custom patterns can’t be locked.

​
Add a custom pattern

Use a custom pattern for a structured ID that the built-in rules don’t cover, such as a customer account number. Write the format as a regular expression. Don’t enter real values.
1

Start a pattern

In Admin Settings → Guardrails, click Add pattern. A new pattern starts at the Workspace scope.
2

Name it

Enter a Name your team will recognize, such as Customer account ID.
3

Pick a category

Choose a Category from the list or type your own, such as customer-id. Agents see the category in the placeholder, for example ct:pii:v3:customer-id:<hash>. Categories that built-in rules use, such as email, are reserved.
4

Enter the pattern and save

Enter the regular expression in Pattern, for example \bACC-\d{6}\b for ACC- followed by exactly six digits. The \b word boundaries stop it matching inside a longer ID such as ACC-1234567. Click Save.Patterns use Rust regex syntax, case-sensitive by default. Add (?i) at the start to ignore case. Lookarounds and backreferences aren’t supported. To try a pattern first, use a tester set to the Rust flavor, such as regex101.Success state: the pattern appears in the table as Custom, at the Workspace scope. CloudThinker checks the pattern on save, and an invalid or too-broad pattern shows an error instead (see Troubleshooting).
There’s no match preview, so make the pattern specific. A broad pattern, such as any UUID, can hide values agents need to do their work.

​
Limits

To use a pattern across the organization, an organization Owner or Admin moves it to Organization with its scope control. It then shows in every workspace’s table, and only organization Admins can edit, move, or delete it. An organization pattern takes a slot in every workspace. Moving one there, or adding one, is refused when any workspace would go past 5. Free a slot in the fullest workspace first.

​
Change or remove a pattern

​
Troubleshooting

The error message tells you which check failed.
An organization Admin locked it. Ask them to unlock it, or keep it on.
It’s an organization pattern. Only organization Owners and Admins can change it.
Admin Settings is for organization Owners and Admins. A workspace Admin can open only its Guardrails page. If you have one of those roles and still don’t see the page, Guardrails may not be enabled for your deployment. Contact CloudThinker support.

​
Next steps

Data Protection

See how pasted and printed secrets are handled

Security and Trust

Review every security control in one place