Skip to content
redactsure
Book a demo

Explore.

Explainer · By Chris Sowa · Published
Last updated

What Is Runtime Tokenization for AI Agents?

Runtime tokenization for AI agents replaces sensitive values with consistent placeholder tokens at the moment an agent is about to read them. Its defining feature is timing: the substitution happens during a live run while the source record stays unchanged. Get the timing wrong and the model holds the real values before any control has acted.

A database record becomes protected fields at a gate before entering a computing window.

Runtime tokenization for AI agents replaces sensitive values with consistent placeholder tokens at the moment an agent is about to read them. Its defining feature is timing: the substitution happens during a live run while the source record stays unchanged. Get the timing wrong and the model holds the real values before any control has acted. The substitution takes place during the run, not in a stored database long before the run begins. The original value stays in the source system. The model receives the token, reasons about the work using the token, and never holds the real value in its context. When a real value is required at an approved destination, it is resolved there, at that moment. Applied at the point where a screen is rendered, before any model reads it, the approach is render-layer tokenization: the model works with SSN_001 and ACCT_001, and real values resolve only at approved destinations at the moment of action. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • The defining feature is timing. Tokenization happens during execution, in the path between the application and the model, so the decision can depend on the task being performed rather than on how a database was designed (PCI Security Standards Council, 2011).
  • The underlying concept is older than AI agents. PCI guidance defines tokenization as replacing a sensitive value, originally a card number, with a substitute that has no exploitable meaning outside the tokenization system (PCI Security Standards Council, 2011).
  • A runtime token must be consistent within a task. If the same customer appears on three screens as three different tokens, the agent cannot tell it is the same customer and the work breaks (RedactSure Research, 2026).
  • Runtime tokenization limits what an attack can collect. Material an agent never received cannot be extracted from it, which is why the control matters for prompt injection as well as for ordinary disclosure (OWASP, 2025).
  • It is not encryption, not masking, and not redaction. Each of those changes data in a different place, for a different purpose, with different reversibility; PCI guidance draws the same line between a token and an encrypted value (PCI Security Standards Council, 2011).
  • Tokenization does not govern actions. OWASP treats prompt injection and excessive agency as separate risks requiring their own controls, so an agent holding only tokens can still be directed to a harmful action (OWASP, 2025).

What does runtime mean in this term?

Runtime is the period when a program is executing, as opposed to the periods when data is being stored, migrated, or analyzed offline. Applied to tokenization, the word marks a specific architectural choice. Traditional tokenization projects work on data at rest: a column of card numbers or account numbers is replaced with tokens, the mapping is held in a vault, and applications are rewritten to work with the stored tokens. That is a data architecture project, and it is usually measured in quarters.

Runtime tokenization makes the substitution later, at the point of use. The source record is unchanged. The application still stores and displays the real value to authorized staff. The substitution happens in the short interval between the application rendering that value and a model reading it. Because the substitution sits at the point of use, it can cover systems the organization cannot rewrite: a claims platform bought from a vendor, a payer portal owned by someone else, an older finance system with no integration surface.

That placement also means the policy can be task specific. The same record can be presented differently to two different pieces of work. A task that reconciles totals may need amounts and dates but not names. A task that drafts a letter may need a name at the destination but not an account number in the model's context. A stored tokenization scheme cannot easily express that difference, because the stored form is fixed before any task exists.

How does a runtime token work during a run?

A typical sequence has five steps. First, a policy identifies which classes of value are protected for this workflow: identifiers, account numbers, contact details, or any value a policy owner names. Second, as each screen or document is rendered for the agent, protected values are detected and replaced with tokens before the content is passed to the model. Third, the token is consistent, so repeated appearances of the same value produce the same token throughout the task. Fourth, the agent performs its reasoning and prepares its actions using tokens, which is enough for most comparisons, matching, sorting, and drafting work. Fifth, if the task reaches an approved action that requires a real value at a specific destination, the value is resolved at that destination under the approval rules for the run.

Two properties do most of the work. Consistency lets the agent keep track of entities across screens, which is what makes the approach usable rather than merely safe. A token that changed on every screen would protect data and destroy the task. Irreversibility from the model's side matters equally: the token must not encode the original value in a way the model or an attacker can decode. PCI guidance makes the equivalent point for payment tokens, noting that a token should not be mathematically reversible into the original number and that the mapping must be protected separately (PCI Security Standards Council, 2011).

Note what is absent from the sequence: a permanent change to the source data, and a requirement that the application offer an interface for the substitution. Both follow from placing the control at the point where the agent reads.

How is it different from stored tokenization, encryption, and masking?

Approach Where it acts Is the original recoverable? What the model receives
Stored tokenization In the database, before any task Yes, through a protected vault Tokens, if the application serves them
Runtime tokenization In the reading path, during the run Yes, only at an approved resolution point Tokens chosen for this task
Encryption In storage or in transit Yes, by anyone holding the key Real values, once decrypted for use
Masking In a display or a copy Often no, the value is truncated or altered A partial or altered value

Encryption is the most common source of confusion. Encryption protects data from parties who do not hold the key, during storage and transmission. It does not protect data from the party who is supposed to use it, because that party decrypts it. When a model is the user, the decrypted value is the value in its context. Runtime tokenization addresses the different question of whether the working party needs the value at all.

Masking and redaction change what is shown, usually by removing characters or covering a region. They are useful controls. Their weakness for agent work is that they are usually destructive or partial: a masked value cannot be matched reliably against the same value elsewhere, and a redacted document cannot support a later approved resolution step. A token preserves a stable identity for the value without carrying the value itself. That is the property an agent needs in order to keep working.

What decides which values become tokens?

A tokenization decision is a policy decision, and it should be traceable to a named owner. In practice the decision has three layers. Field level rules cover values whose sensitivity is structural: government identifiers, bank account numbers, card numbers, dates of birth, and credentials. Pattern level rules catch values that appear in free text, such as an identifier typed into a notes field by a member of staff. Task level rules reflect purpose: even a value that is normally acceptable may be unnecessary for a particular job, and a value that is normally protected may be required as readable task data in a narrow case.

The NIST Privacy Framework's data management practices support the purpose layer, framing processing limits in terms of what a defined purpose requires (NIST, 2020). The NIST AI Risk Management Framework adds the governance layer, expecting organizations to map the data a system uses and to manage the risks that follow from that mapping (NIST, 2023). Neither framework prescribes tokenization. They supply the reasoning a policy owner uses to decide what should be tokenized, and the expectation that the decision be documented rather than improvised by an engineer during setup.

Errors run in both directions. Under tokenization leaves real values in context and defeats the control. Over tokenization removes information the task needs, for example tokenizing the amounts in a reconciliation task, and produces an agent that fails in ways staff then work around. A reviewer should therefore ask for examples of both: a value that was tokenized, and a value that was deliberately left readable, with the reason for each.

What are the limits of runtime tokenization?

There are four limits. First, the model still receives the rest of the task context. Notes, amounts, dates, and narrative text may themselves be sensitive, and tokenizing identifiers does not make a whole record harmless. Second, inference can leak information. Combinations of apparently harmless fields can identify a person, particularly in small populations, and a token does not prevent that. Third, detection is imperfect. A value written in an unusual format, embedded in an image, or split across fields may not be recognized as protected, so the control's coverage is only as good as its detection and its testing.

Fourth, tokenization does not govern actions. An agent holding only tokens can still be directed to perform a harmful or mistaken action, which is why OWASP treats prompt injection and excessive agency as separate risks requiring their own controls (OWASP, 2025). Runtime tokenization reduces what an attacker can collect and what a careless run can disclose. It does not decide who approves a payment, and it does not make a model follow instructions faithfully. Organizations that present it as a complete agent security program are overstating a single, useful control.

There is also an operational cost. Tokenization adds a step in the reading path, requires policy maintenance as applications change, and needs monitoring for missed values. Those costs are real and should be weighed against the alternative, which is either not using agents on sensitive work or accepting full values in model context.

Where does RedactSure sit?

RedactSure gives the timing question a concrete answer: its substitution occurs at the render layer during the live run, before any model reads the screen. AI co-workers do real work across an organization's applications inside a governed environment, with no per-application integration and no change to user permissions. Every identifier chosen by policy is replaced by a consistent token, so the model holds SSN_001 and ACCT_001 throughout its reasoning while the source record keeps its real values untouched. The model receives the task's fields rather than a picture of the page. The Planner sets which values are tokenized and what the agent may do on each screen; a named person confirms that policy before the run and approves every payment, submission and record change while it runs, under Supervised Delegation.

Only when an approved action reaches an approved destination does a real value resolve, which is why runtime tokenization in RedactSure protects the run itself rather than tidying up after the model has already seen too much. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's own SIEM. Keys stay with the customer, and the model is swappable. Deployments are in pilot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page is definitional and rests on published standards and framework documents, all read as of October 13, 2026. The PCI Security Standards Council's Tokenization Guidelines Information Supplement (2011; industry standards guidance) supplies the established meaning of tokenization and the distinction between a token and an encrypted value. The NIST Privacy Framework Version 1.0 (2020; official guidance) and the NIST AI Risk Management Framework 1.0 (2023; official guidance) supply the data minimization and AI risk governance reasoning. The OWASP Top 10 for LLM Applications 2025 (community standard), specifically the prompt injection and excessive agency entries, supplies the related agent risks. Product statements about RedactSure are confined to the design facts the company publishes.

No benchmarks, latency measurements, or detection accuracy figures are reported for any implementation, because no primary source consulted published comparable figures for runtime tokenization in agent reading paths. No hands-on testing of any named product or platform was performed, and nothing here should be read as an evaluation of a specific vendor's detection coverage, which would require testing that was not done. Vendor features and framework editions change; the page carries its date and is revised when the source documents change. The claims platform, payer portal, finance system and reconciliation examples describe record and task types, not any organization; no customer or prospect is described.

Whether runtime tokenization, or any configuration of it, meets an organization's obligations under PCI DSS, privacy law or its own policies is a determination for that organization's counsel, assessor, privacy officer and security and compliance officers, not for a research page. A policy owner inside the organization decides which values are tokenized for each task and records the reason.

What the record shows

Runtime tokenization is defined by when the substitution happens. Replacing a sensitive value during a live run, in the path between the application and the model, lets the decision reflect the task being performed instead of the way a database happened to be designed months earlier. The original value stays in the source system, the model works with a consistent token, and a real value is produced only where an approved destination requires it. That timing is also what gives the control its protective effect: material the model never received cannot be repeated, transformed, or extracted from it. The term should not be stretched to cover encryption, masking, or redaction, which change data in different places, for different purposes, and with different reversibility. The test for any implementation is to ask for one screen of a real workflow as the model received it, and for one value that was tokenized and one that was deliberately left readable, with the reason for each.

Frequently asked questions

Does runtime tokenization change the data stored in our systems?

No. The substitution happens in the reading path during a run, not in the stored record. The original value stays in the source system, which continues to hold and display it for authorized staff as before. What changes is the representation prepared for the model: the value in that representation is replaced by a token. If the run ends, nothing in the database has been altered, converted, or re-keyed. That is the difference from stored tokenization, where values in a database are replaced as part of the storage design.

Why does the token have to stay the same throughout a task?

Because the agent must recognize what it is working with. If a customer appears on three screens under three tokens, the agent cannot tell the screens describe one customer, and it will treat them as separate cases or fail the task. Consistency preserves the relationships the work depends on: this invoice belongs to that account, this note refers to that record. The token carries identity without carrying the value, which is what allows the agent to reason about the work while holding none of the sensitive material.

Is runtime tokenization just another name for encryption?

No, and the distinction is practical rather than pedantic. Tokenization, in the established PCI sense, replaces a sensitive value with a substitute that has no exploitable meaning outside the tokenization system. Encryption transforms a value mathematically so that a key holder can reverse it, and anything holding the key and the ciphertext effectively holds the value. The two also sit in different places: encryption usually protects data in storage or in transit, while runtime tokenization acts at the moment of reading, in the representation the model is about to receive.

Does runtime tokenization stop prompt injection?

It limits what an injection can collect, not whether one occurs. A model working on tokens can still be persuaded to follow an injected instruction, which is why OWASP lists prompt injection and excessive agency as separate risks with their own controls. What changes is the payload: an attacker who extracts the context gets SSN_001 and ACCT_001, not the values. The consequential action, a payment or a record change, still needs a named person's approval under a separate control.

Does runtime tokenization require changing or integrating the applications?

No. Because the substitution happens between the application rendering a value and the model reading it, the application does not need an interface for it and the stored data is not altered. That is what lets the control cover a vendor claims platform, a payer portal owned by another party, or an older finance system with no integration surface. Policy maintenance is still needed as applications change, and missed values need monitoring.

What values should be tokenized, and who decides?

A named policy owner decides, in three layers. Field level rules cover structurally sensitive values: government identifiers, bank account and card numbers, dates of birth, credentials. Pattern level rules catch identifiers typed into free text. Task level rules reflect purpose, so a reconciliation task keeps amounts readable while a letter drafting task keeps account numbers out of context. The NIST Privacy Framework and AI Risk Management Framework supply the reasoning; the decision should be documented, with an example of a tokenized value and a deliberately readable one.

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.