Should this block or flag?

Block on Tool input where you can enforce. Flag elsewhere — by the time a secret is in user input, blocking prevents nothing.

Does a hit mean we were attacked?

Usually not. Most hits are people being helpful with a token they should not have pasted. It is still a rotation.

Do I still need this if we use a secrets manager?

Yes. The check catches secrets in conversations, which is precisely the path a secrets manager does not cover.

Introduction

Secrets end up in agent traffic constantly, and almost never on purpose. A user pastes a token to ask why an integration is failing. A tool returns a config object with a key still in it. An agent helpfully echoes back what it was given.

None of that is malicious, and all of it is a leaked credential.

What it detects

"Secrets — API tokens, passwords, private keys."

Choose which detectors to run and the likelihood for each (High, Medium or Low; default High): API token / key, Password, Private key, AWS access key, OAuth client secret, Database connection string, SSH private key, Encryption key.

Where to run it

Applied on	Catches	Priority
`User input`	Someone pasting a credential into a conversation	High — the common case
`Tool input`	A secret leaving in a call to another system	Highest — this is exfiltration
`Tool output`	A secret arriving from a data source or config	High — and often a finding about the source
`Agent output`	The agent repeating a secret back	High

The shipped ISO 42001 pack runs this check on Tool input, which is the reading worth copying: a secret in a conversation is a problem, and a secret being sent somewhere is an incident.

Actions

Flag, Block and Mask are available. The choice is unusually clear-cut here.

Block on Tool input — A credential heading out of your boundary is one of the few cases where failing the interaction is obviously correct.
Mask on Agent output — The agent can still answer; the secret does not appear.
Flag on User input — The secret is already exposed by the time you see it — blocking does not un-expose it, and the record is what triggers rotation.

"A flagged credential is a rotation ticket. The incident is not the end of the work — it is the beginning of it."

What to do with a hit

Unlike most checks, a true positive here demands action outside UnifyApps.

Treat the credential as compromised — It has been in a conversation, a log and an incident record. Rotate it.
Find out where it came from — A secret in Tool output means a data source is returning credentials — a finding about that system, not the agent.
Restrict who can read the incident — The incident title contains the secret.

Known limitations

The incident contains the credential — Which is unavoidable if the record is to be useful, and is the strongest argument for scoping access to Incidents deliberately.
Detection happens after the content exists — On an advisory connection the secret has already been sent. Rotate rather than assume containment.
Formats outside the detectors may be missed — For an internal credential format with a known shape, add a Regex pattern control alongside this one.

Credentials & Secrets