Shield Log

The Shield Log records every decision AI Data Shield made: what it protected, what it left alone, and which restores it allowed. One record per finding on a protect call, one per token on a restore call, each naming the outcome and the rule behind it.

Read it when a value was not protected or a restore returned less than expected. Because a record names the deciding rule, an unexpected outcome resolves to a specific line of a specific Shield policy rather than to a guess.

To open it, select Audit Logs > Shield Log in the navigation menu.

What a Record Contains

Each record identifies the call, the decision, and the data involved:

Column	Contains
Timestamp	When the decision was made.
Event	Protect or Detokenize.
Outcome	Whether the access was allowed, with denials broken out by reason.
Token	The token minted or accessed. Empty on a protect record whose value was masked or left in the clear, because no token exists in those cases.
Finding	On a protect record, the classifier that matched and what ALTR did with the value. Restore records have no finding.
Application	The application that made the call.
Strategy	The tokenization strategy the winning rule minted the token under. Empty on a finding that minted no token, and on a token from outside your organization.
Deciding Rule	The rule statement that decided the access, by its Statement ID. Blank when no rule decided – an implicit denial, or a check that runs before policy.

One call can produce many rows. Every row from one call carries the same request identifier, which is how you reassemble a single protect call from its rows. A record can take a minute or two to appear after the call it describes.

Selecting a record shows the tags that were in play, kept as 3 separate sets rather than merged:

Identity Tags – the tags registered on the calling application itself.
Requester Tags – the tags asserted on the request. These can differ from the application’s own.
Resource Tags – the tags stored on the token when it was minted.

For a record that carries a token, the detail also shows its Determinism Context – the scope its protect call set, or None – the default scope when the call set none. See Protecting and Restoring Data.

Those sets are the inputs a rule’s conditions matched against. Keeping registered identity apart from caller-asserted tags matters for the reason Shield Policy gives: the log shows which of the two a rule actually matched.

Selecting a token follows it – every record for that token across separate requests, within the date range you are viewing. A range covers at most 31 days, and a single query returns at most 10,000 rows; narrow the range if you reach that.

Outcomes

An outcome is an allow or one of 3 denials, separated because they call for different fixes:

Outcome	Meaning
Allowed	Policy allowed the access.
Deny rule	A deny rule matched. The record names the policy and rule that decided.
No rule matched	No allow rule matched, so the implicit denial applied.
Unknown token	The token is not in your organization – from another organization, or never valid.

No rule matched means your policy is silent and the default took over – add an allow rule. Deny rule means your policy says no – amend the rule that fired. Unknown token is the one denial policy did not decide; every other restore outcome resolves to a rule or its absence.

A restore policy allowed can still return nothing, when the stored value could not be decrypted. The record stays Allowed and carries a Restore failed flag alongside it, because the policy verdict and the decryption failure are separate facts: policy is correct and the value is gone. The restore call itself cannot tell you which – it returns any token it could not resolve as itself – so the log is the only place the reason appears.

What a Protect Record Reports

A protect record’s Finding names the classifier that matched and the action taken – Tokenized, Masked, or Left in the clear.

Left in the clear means Shield found something sensitive and did not protect it. Usually that pairs with a denial, but it also appears on an Allowed row when policy called for tokenizing a value larger than 65,536 bytes. Read the outcome and the action together rather than inferring one from the other.

Every finding is recorded, so the log separates text that held nothing sensitive from text Shield was not permitted to protect.

What the Log Does Not Contain

The log records tokens, never values. A token is a surrogate and not sensitive on its own, so it appears in full and is searchable. The matched text, the underlying value, and the rendered result of a mask or restore are never written.

Configuration changes are not here either. Creating an application and editing a policy go to the System Audit Log with the other platform events. The Shield Log covers data access; the System Audit Log covers configuration.