Shield Policy

A Shield policy decides which findings AI Data Shield protects, how, and which applications can restore a protected value later.

A policy holds two kinds of rules. Protection rules run when your application submits a payload; detokenization rules run when it asks for a value back.

How a Shield Policy Works

Shield evaluates the rules once per finding on the way in, once per token on the way back. Three principles decide the outcome, and rule order never matters:

• A matching explicit deny rule wins over any matching allow rule.
• Among matching allow rules, the least permissive protection is the one applied.
• A value no rule matches is denied.

The protection tables below are ordered most to least permissive, so the second principle is readable off them: when two allow rules match, the one further down wins.

The third principle means the two flows fail differently. Denied on the way in leaves the value in the clear, reported with no action taken. Denied on the way back means the value is not returned – there is no built-in permission to restore anything, so a token stays unreadable until a rule allows it.

One check runs before policy on a protect call: the calling application must be allowed to use the collection it names. It is not a rule and no rule overrides it. On a restore, nothing runs before policy except the token lookup itself – a token from outside your organization is unknown, and everything else is decided by the rules below. See Registering an Application.

Protection Rules

Protection rules decide what happens to each finding on the way in. A rule states that a matching value should protect or leave in clear; an allow rule names the protection. The two ways of leaving a value alone differ under the principles above: leave in clear is a deny and overrides every matching allow, while No Mask is an allow that a less permissive matching allow can override.

The protections are:

Protection	Result
No Mask	The value is left in the clear.
Tokenize	The value is stored encrypted and replaced with a surrogate that can be restored later. Requires a tokenization strategy.
Mask	The value is transformed and replaced. Nothing is stored, so a masked value can never be restored.

Tokenize is the only protection that survives a round trip. Mask is a decision that the value is not coming back.

Tokenization Strategies

A Tokenize rule also states how the token is minted, as one of 4 strategies. There is no default – a protection rule cannot be saved until its strategy is chosen:

Strategy	Repeated values
Vaulted (Deterministic)	The same value resolves to the same token.
Critical (Deterministic)	The same value resolves to the same token.
Vaulted	Every occurrence mints a new token.
Critical	Every occurrence mints a new token.

Deterministic decides whether one value carries one token: a deterministic strategy gives a repeated value the token it already has, which preserves referential integrity across calls but lets anyone holding the text see that two spans held the same value. A non-deterministic strategy mints a fresh token every time, so nothing links two occurrences. Critical and Vaulted differ in how ALTR stores the protected value; the choice does not change how tokens behave in your text or on a restore.

The table is ordered most to least permissive, like the others on this page, so when two allow rules match one finding, the strategy further down the table wins.

A deterministic strategy repeats a token only within the same determinism context, a scope the protect call sets. See Protecting and Restoring Data.

Caution

Deterministic tokens can be defeated by guessing. A user with access to tokens and the ability to tokenize new data can look up which value a token belongs to by guessing the value and seeing which token is returned. Deterministic tokens only repeat within a context, which defaults to global for your organization. Prefer non-deterministic tokens where your use case allows it, or use narrow contexts with deterministic strategies to minimize the risk of token guessing.

Whatever the strategy, a token is random – never computed from the value it replaces, so nothing about the value can be recovered from the token alone.

Masking Types

Mask requires a masking type, which decides how the replacement renders. This table is ordered most to least permissive as well, so when two allow rules both mask one value, the type further down wins:

Masking type	Renders
Email Hash	The local part hashed, the domain intact.
Email Mask	The local part masked, the domain intact.
Show Last Four (Hash)	The last 4 characters, the rest hashed.
Show Last Four	The last 4 characters, the rest masked.
Full Mask (Hash)	A hash of the whole value.
Full Mask	One mask character per character of the original.
Custom Date Constant	A fixed date you supply.
Classification Constant	The name of the classification that matched, in place of the value.
Constant	A fixed string you supply.
Null Mask	An empty string.

Classification Constant is the masking type written for prompts: it replaces the value with the shape of what was there, so a model knows an email address was present without receiving it.

Hashing masking types key their hash to your organization. The same value hashes identically within one organization and differently in another, so a hash is never a bare hash of the underlying data.

Note

Shield’s masking types are its own list, separate from the masking types a database masking policy applies. The options overlap today, but the two are configured independently – a change to one does not follow to the other.

Detokenization Rules

Detokenization rules decide which tokens an application can turn back into values. A rule states that a matching token may restore or may never restore; an allow rule renders the result as Original Value or as any masking type above.

Rendering through a masking type is how one policy serves several applications from the same text: one gets the original value, another gets Show Last Four from the same token.

Masked values never reach this flow – masking stores nothing, so there is no token to ask about.

Conditions

Every rule needs at least one condition; nothing matches everything by default. You author a condition as 4 parts – scope, attribute, operator, value.

The scope decides what the condition looks at:

• request – who is asking. The calling application, the tags registered on it, and any tags the call itself presents. The registered tags apply even when a call sends none.
• resource – what is being acted on. On the way in, the classification behind a finding; on the way back, the tags stored on the token when it was minted.

Attributes ALTR sets itself sit under ALTR Reserved at their literal names: altr.application-id, altr.classification-name, altr.collection-name, altr.determinism-context, and altr.classification-tags. Your own tag keys sit under Your own tags; Custom lets you type a key no data carries yet, so a rule can precede its data.

Note

altr.classification-tags is evaluated on protect only – it is not stored on a token. A detokenization rule keyed on it never matches, which on an allow is merely inert and on a deny means the deny silently never fires. To reason about a classifier’s tags on the restore side, match the tag’s own key instead, as resource:tier rather than resource:altr.classification-tags.

altr.determinism-context is the scope a token’s protect call set for deterministic tokenization – see Protecting and Restoring Data. Unlike every other attribute, its value is matched exactly as written, case included: a rule on fruit never matches a token minted under Fruit. A rule with the wrong casing saves without complaint and then silently never fires – on a deny, that is a hole. Copy the value from the code that sets it rather than retyping it.

The operator is equals, is any of for a set, or like for a whole-string pattern. With more than one condition, you choose whether any or all must hold.

Caution

A tag splits at its first colon only, so region:us:east is the key region with the value us:east. Write that as the key region matched against us:east – never as a key of region:us:east, which is valid syntax naming an attribute that cannot exist. Such a condition is always false: harmless on an allow, but on a deny it means the deny never fires.

Once saved, a rule reads back on the policy list as a sentence rather than as its parts – Data is classified as, Requesting application is, Token’s determinism context is, and so on. Same rule, two renderings.

Tags on a Token

Everything Shield knows about a value at protect time becomes a tag on its token: the call’s tags, the application’s own tags, and the matching classifier’s tags. Detokenization rules match against those, which is why a rule written on a classifier’s own tag key works on both flows.

The layers combine by union – every tag survives, and a key can hold more than one value. A token tagged env:prod and env:dev matches a condition on either.

Caution

Because the layers union rather than override, an application can present a tag whose key a classifier also sets. Both values land on the token, so an allow rule matching the application’s value fires. To make a classifier’s value decisive, write an explicit deny against it – deny beats allow regardless of what the caller attached.

Restoring Only What an Application Protected

A detokenization rule can let each application restore only the tokens it minted. It compares the application stored on the token against the one making the request, so one rule covers every application without naming any.

Author it early if you run more than one application. Nothing separates applications by default: an organization whose detokenization rules never look at the minting application lets any of its applications restore any token another one minted.

Click Add Template in the drawer to add it ready-made, or author it as an ordinary condition: resource, altr.application-id, equals, and the value ${request:altr.application-id}, which stands for whichever application is calling. ALTRNet shows that reference as written rather than paraphrasing it.

The result is an ordinary rule – editable, deniable, removable – and it fails closed. A token minted with no application recorded does not match.

Caution

Tags a call presents are asserted by the caller. ALTR trusts them because the caller is an authenticated application acting in its own scope, which makes them workable for separating data by conversation, actor, or workload – but any code able to act as that application can present any value. The rule above does not have that weakness, because altr.application-id is stamped by ALTR and cannot be asserted – though it is still only as strong as the application identity itself: it does not defend against a compromised application’s own key. The only boundary that does not rest on policy is the organization – no rule, tag, or identity reaches across one.

Tag keys beginning with altr are the exception: ALTR reserves the prefix, rejects it on anything a client supplies, and stamps those attributes itself.

Create a Shield Policy

To create a Shield policy:

1. Select Policy > Shield Policy in the navigation menu.
2. Click New Policy. ALTR opens the Create Shield Policy drawer.
3. Enter a Policy name.
4. Under Protection Rules, click + Rule Statement, set its conditions, choose should protect or leave in clear, and select the protection an allow rule applies. A Tokenize rule also needs its tokenization strategy; Save stays disabled until one is chosen.
5. Under Detokenization Rules, click + Rule Statement, set its conditions, choose may restore or may never restore, and select how an allow rule renders the restored value.
6. Click Save. ALTR applies the policy to subsequent calls.

Note

ALTRNet calls an individual rule a rule statement and its optional identifier a Statement ID. Name them: the identifier is what the Shield Log reports as the rule that decided an access.

Relationship to the Tokenization APIs

A Shield policy applies to Shield tokens only. It has no effect on Vaulted Tokenization or Critical Tokenization tokens – see AI Data Shield for why the two sets of tokens are not interchangeable.