Skip to content
redactsure
Book a demo

Explore.

Comparison · By Chris Sowa · Published
Last updated

What Is the Difference Between Runtime Tokenization and Data Masking for AI Agents?

The comparison turns on visibility and reversibility: masking leaves part of a value readable, while a token hides the whole value yet can still resolve at an approved destination. An agent working from masked fragments holds real pieces of real values, and still cannot finish a payment or a filing without a separate system or a person supplying the original.

A protected browser field branches into separate token and masking paths.

The comparison turns on visibility and reversibility: masking leaves part of a value readable, while a token hides the whole value yet can still resolve at an approved destination. An agent working from masked fragments holds real pieces of real values, and still cannot finish a payment or a filing without a separate system or a person supplying the original. Data masking hides sensitive values by obscuring part or all of them, often leaving a portion visible so a reader can still recognize the type of a field, while runtime tokenization replaces a policy chosen value with a consistent token at the render layer before any model reads the screen, so the model never receives the original at all (Microsoft, 2026; Skyflow, 2026). That second mechanism is render-layer tokenization. The practical difference is not whether something is hidden, but how much remains visible, where the original is held, and whether the hidden value can be brought back at an approved destination to finish a task. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • Masking commonly preserves partial visibility: Microsoft documents masking functions that expose part of a value, such as the first letter of an email address or the opening characters of a phone number, while covering the rest (Microsoft, 2026).
  • Tokenization, in established guidance, replaces a sensitive value with a surrogate token, and the security of the scheme rests on the original not being derivable from the token alone (PCI Security Standards Council, 2011).
  • Runtime tokenization as described for RedactSure operates at the render layer of an application worked as rendered, before a model reads the screen, rather than inside a database query path (RedactSure Research, 2026).
  • On reversibility, a token is designed to resolve to the original only at an approved destination, while a masked value is presented to be read in its obscured form (PCI Security Standards Council, 2011).
  • Microsoft cautions that dynamic masking should not be relied on alone against a user who can run ad hoc queries and infer underlying values, which makes the visible fragment and the inference path both part of the masked yield (Microsoft, 2026).
  • OWASP ranks prompt injection as LLM01 and sensitive information disclosure as LLM02 for 2025, and the yield of a successful injection is set by what was placed in the model's context before the instruction arrived (OWASP, 2025).

How does data masking decide what stays visible?

Masking starts from a dataset or a database column and asks how much of each value a given reader should be allowed to see (Microsoft, 2026). Microsoft describes dynamic data masking as limiting exposure by masking data to nonprivileged users, with rules defined on designated fields and applied in query results, while the data stored in the database itself is not changed (Microsoft, 2026). Within those rules, a mask can cover a value fully, expose a defined prefix or suffix, substitute a random numeric value within a range, or reshape an email address so that only its first letter and domain suffix pattern remain readable (Microsoft, 2026).

Partial visibility defines many masking deployments. A support worker or a model may need to know that two records share the same final digits, or that a field is an email address, without needing the complete value (Microsoft, 2026). Skyflow makes a related distinction in its AI material, treating mask as a mode in which output remains partially visible, separate from tokenize and from redact, and noting that masked output keeps limited field context without the complete value (Skyflow, 2026). That context is useful for review and testing, and it is also the point of difference from tokenization, because whatever portion remains visible has still been disclosed to the receiver (Microsoft, 2026).

Masking also comes in two timing forms that matter for agents. Static masking produces a transformed copy, so the values in the copy itself are changed before use in a non production setting such as development or testing (Microsoft, 2026). Microsoft notes the same effect when masked data is exported by a user without unmask permission: the imported copy then holds statically masked data (Microsoft, 2026). Dynamic masking leaves the source intact and applies the mask as results are returned, so the outcome depends on the platform enforcing the rule at query time and on the privileges assigned to the requester (Microsoft, 2026). Microsoft also cautions that dynamic masking should not be relied on alone against a user who can run ad hoc queries and infer underlying values (Microsoft, 2026).

For an AI agent, that enforcement point is the limitation to examine. If an agent reads from a masked database view, masking can protect the values behind that view (Microsoft, 2026). If the same agent reads a rendered application screen, an email thread, or a document never produced through that query path, a database masking rule has no occasion to apply, because no covered query produced what the model is reading (Microsoft, 2026).

What does runtime tokenization replace, and where does the original go?

Tokenization replaces the whole value rather than obscuring part of it. PCI Security Standards Council guidance defines tokenization as substituting a surrogate token for a sensitive value, in its case the primary account number, and detokenization as redeeming that token for the original value (PCI Security Standards Council, 2011). The same guidance grounds the security of tokenization in the infeasibility of deriving the original from the token by itself (PCI Security Standards Council, 2011). Skyflow describes a consistent pattern in its documentation: tokens are pseudorandom, originals are held in a secure isolated store, and an original is exchanged back only when it is required (Skyflow, 2026).

Runtime tokenization applies that substitution during a live task rather than to a stored dataset. In the RedactSure design, sensitive values chosen by policy are replaced by consistent tokens at the render layer before any model reads the screen. Consistency matters for reasoning: if the same customer appears on three screens, the agent sees the same token each time and can follow the relationship between records without seeing the underlying name or number. The original is not carried in the model context, and real values resolve only at approved destinations at the moment of an approved action.

How do masking and runtime tokenization compare side by side?

The table below compares the two approaches on layer, timing, reversibility and custody of the original, and effect on task completion.

Axis Data masking Runtime tokenization
Primary layer Database column, dataset copy, or query result (Microsoft, 2026) Render layer of an application screen, before model reading
What the reader receives A partially or fully obscured value, often with some original characters or format retained (Microsoft, 2026) A consistent surrogate token with no part of the original value shown (PCI Security Standards Council, 2011)
Timing Static, when a copy is made, or dynamic, when a query result is returned (Microsoft, 2026) During the run, at the moment a screen is rendered for the model
Where the original is held In the source database for dynamic masking, unchanged; replaced within the copy for static masking (Microsoft, 2026) Outside the model context, resolving only at an approved destination
Reversibility Dynamic views can be unmasked for privileged roles; a statically masked copy is not designed to restore originals (Microsoft, 2026) Detokenization is part of the concept, controlled and limited to approved use (PCI Security Standards Council, 2011)
Typical strength Realistic, partially readable data for testing, support, and role based database access (Microsoft, 2026) Letting an agent reason across screens without holding real values

Can the workflow still finish its task under each approach?

Task completion depends on whether the final step needs the real value, a recognizable fragment, or only a relationship between records. Many analytical and testing tasks need only the fragment or the relationship, and masking serves them well because a masked dataset can retain format and enough visible context to work with (Microsoft, 2026). A quality assurance team, for example, can test a billing flow against a masked copy without holding production account numbers (Microsoft, 2026).

A live operational workflow is different. Submitting a payment, updating a record, or sending a letter to a named person eventually requires the actual value at the destination system. Under a masking only design, the agent holds an obscured value produced for reading, not a reference that resolves at the destination, so a separate system or a person must supply the real value at that final step (Microsoft, 2026). Under runtime tokenization, the token is a reference by design, and detokenization is the defined reverse operation that returns the original when it is required (PCI Security Standards Council, 2011). In the RedactSure design, that resolution is narrowed further: real values resolve only at approved destinations, at the moment of an action approved by a named person.

There is a corresponding cost. Tokenization requires a governed store and a controlled resolution path that masking for a test copy does not need, because the token is only useful if its link to the original is protected (PCI Security Standards Council, 2011). Skyflow describes originals being held in a secure isolated store for exactly that reason (Skyflow, 2026).

What does a successful prompt injection collect under each approach?

OWASP ranks prompt injection as LLM01 and sensitive information disclosure as LLM02 in its Top 10 for LLM Applications 2025, and the two risks combine in an agent that both reads untrusted content and holds task data (OWASP, 2025; OWASP, 2025). An injected instruction hidden in a page, message, or record can direct the agent to reveal or forward what is present in its context (OWASP, 2025). The yield of that attack is therefore set by what was placed in the context before the instruction arrived.

Under masking, the yield is the masked form and whatever portion of each value the mask left visible, together with any unmasked fields the task required (Microsoft, 2026). That is a materially smaller yield than a full record, but the visible fragments are real fragments of real values, and Microsoft warns that values can sometimes be inferred through repeated querying in the dynamic database setting (Microsoft, 2026). Under runtime tokenization, the yield in the RedactSure design is tokens and the remaining task context. A token on its own does not disclose the original, which is the property PCI guidance relies on (PCI Security Standards Council, 2011).

Injection resistance is not only about data yield. The NIST AI Risk Management Framework organizes risk work under Govern, Map, Measure, and Manage, which supports treating injection as a governed risk rather than as a problem any single transformation solves (NIST, 2023). In the RedactSure design, a successful injection still does not complete a consequential action by itself, because that action stops for approval by a named person. Masking products, as documented by Microsoft, address data presentation and do not claim that action approval function (Microsoft, 2026).

Which kind of work suits masking, and which suits runtime tokenization?

Masking suits work organized around datasets: creating safer copies for development and testing, and limiting what database users with different roles can see in query results (Microsoft, 2026). Its limits are documented by its own vendor, including the warning that it is a complement to auditing, encryption, and access control rather than a complete protection on its own (Microsoft, 2026).

Runtime tokenization suits work organized around a live agent reading rendered applications. The deciding conditions are that the agent reads screens rather than only querying a masked database, that the same values recur across steps and must stay linked, and that a real value is needed at the end of the task but not during the reasoning that leads there. Where those conditions do not hold, tokenization adds a vault and a resolution process that the work may not require (Skyflow, 2026).

Where does RedactSure sit?

For live agent work that ends in a real action, the reference form is what RedactSure supplies. AI co-workers work across an organization's applications inside a governed environment, with no per-application integration and no change to user permissions. Every sensitive value chosen by policy is replaced by a consistent token at the render layer before any model reads the screen, so the model is handed the task's fields with ACCT_001 and CARD_001 rather than a masked fragment such as the last four digits of a card.

A masked fragment cannot supply what a payment or a filing needs at its final step. A RedactSure token is built to resolve to the real value only at an approved destination, at the moment a named person approves the action, under Supervised Delegation. The Planner sets which values are tokenized and what the agent may do on each screen; a named person confirms that policy. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. Keys stay with the customer, the model is swappable, and deployments are in pilot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

The page is a definitional and architectural comparison. It rests on the PCI Security Standards Council's Tokenization Guidelines Information Supplement (2011; official guidance) for the definitions of tokenization and detokenization and the security property of a token, on Microsoft Learn documentation for dynamic and static data masking in SQL Server and Azure SQL (vendor documentation), on Skyflow documentation for the distinction between tokenize, mask, and redact modes and for vault custody of originals (vendor documentation), and on the OWASP Top 10 for LLM Applications 2025 entries LLM01 and LLM02 and the NIST AI Risk Management Framework (standards and official guidance) for risk framing. All sources were read as of October 13, 2026.

No product testing, benchmarks, or measurements of either approach in a deployment are reported, and none was performed; no hands-on testing of Microsoft or Skyflow products took place. Microsoft masking documentation addresses database access rather than browser agents, so statements about masking coverage of rendered screens are reasoning from the documented enforcement point, not a vendor claim. Vendor features and documentation change; the page carries its date and is revised when the documentation changes. The billing, payment, and letter examples describe task types, not any organization; no customer or prospect is described. For RedactSure itself, the page relies only on the design the company has published, and deployments are in pilot.

Whether masking, tokenization, or a combination meets an organization's requirements, including any PCI DSS scoping question, belongs to its counsel, assessor, and its security and compliance officers, not to this page.

What the record shows

Masking and runtime tokenization both hide values, but they leave the reader holding different things. Masking leaves a readable fragment: part of an address, a field's shape, or the final digits of a number, and dataset work is the setting where that fragment is the object, in test copies, support views, and role based database access. Runtime tokenization leaves a reference: a consistent token that discloses no part of the original and follows the same entity across screens. A fragment form stays tied to copies and views where nobody has to complete the underlying transaction, while a reference form lets an agent finish a live task inside applications as rendered, working from tokens throughout. The test is to pick one screen of the workflow and ask what the model received for it, whether any part of a real value was in it, and how the real value reaches the destination at the final step.

Frequently asked questions

Does masking a database protect an agent that reads screens?

Only where the screen's content actually came through a masked query path. Microsoft documents masking as a rule applied to designated database fields in query results, or as a transformed copy. A rendered screen, an email thread, or a document that no covered query produced gives the masking rule no occasion to apply. An agent that reads applications as rendered needs a control at the render layer, before the model reads the screen.

Can a masked value be turned back into the original?

It depends on the form. A dynamically masked view can be unmasked for privileged roles, since the source data itself is unchanged. A statically masked copy is not designed to restore originals, because the values in that copy were changed. Neither form is a reference built for redemption at a destination the way a token is, which is why a masking only design needs a separate path to supply the real value at the final step.

What can an injection collect from masked data?

The masked form of each value, plus whatever portion the mask left visible, and any unmasked fields the task required. Those visible fragments are real fragments of real values, so the yield is smaller than a full record but not empty. Under runtime tokenization, the yield is tokens and the remaining task context, and in the RedactSure design the consequential action still stops for a named person.

Is dynamic data masking enough on its own to protect sensitive data?

Not by Microsoft's own account. Its documentation describes dynamic data masking as a complement to auditing, encryption, and access control rather than a complete protection, and cautions that a user able to run ad hoc queries may infer underlying values. For an AI agent, the added limit is scope: the rule applies to query results from designated fields, not to screens, documents, or messages the agent reads elsewhere.

Why do tokens need to be consistent across screens?

Because the agent has to follow relationships between records without seeing the values that link them. If the same customer appears on three screens and receives the same token each time, the agent can tell that the three records belong together and carry the task forward. A fresh token on every screen would break that link, and a masked fragment would restore it only by exposing part of the real value.

Where is the original held under runtime tokenization, and when does it come back?

Outside the model context. In the RedactSure design, the token is a reference, and the real value resolves only at an approved destination, at the moment a named person approves the action, such as a payment or a record change. PCI guidance describes the same controlled detokenization as the defined reverse operation, limited to approved use, with the security of the scheme resting on the original not being derivable from the token alone.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.