Guide · By Chris Sowa · Published
Last updated
How to Secure AI Agents That Navigate Across Applications: One Token Per Identifier, One Environment, One Named Person
Run the agent in one environment you own that tokenizes every screen, keep 1 token per identifier across 5 applications, and 1 named person approves each consequential action.
62% experimenting · 23% scaling · 1 named person
McKinsey's State of AI 2026 found 62% of organizations experimenting with AI agents and 23% scaling them anywhere (CX Today, 2026). The gap between those numbers is the crossing. A claim is not one application's work. It is five: the claims platform, the policy system, the industry loss database, the payment portal, the adjuster's mailbox. The agent that does the whole task carries the claimant across all five screens, and the SSN travels with it.
You are probably solving this one of three ways. An agent on the employee's desktop, with the whole desktop in reach. A vendor's cloud computer, where the vendor reads the page in full and holds the record. Or a connector per application, where every call returns the whole object. Each puts the real identifiers inside the model at every hand-off.
Secure the crossing by giving the model one task-scoped token per identifier on every screen, inside one environment you own, with one named person in front of each payment, submission and record change. A railway signal box let the signalman set any route, and the interlocking made a conflicting one impossible to set. Build the agent's interlocking the same way, and name the signalman.
The crossing is where identifiers leak, and a claim crosses 5 applications
A property claim touches the claims platform, the policy system, the industry loss database and the payment portal, with the adjuster's mailbox between them. An invoice crosses the ERP, the supplier portal, the approval thread, the bank portal and the mailbox. At least one application belongs to another organization, so no integration project can schedule an API on their behalf.
Each hand-off reads a real value on one screen and types it into the next. If the model holds the SSN at step one, it holds it at every step after.
This is where AI programs stop. The PII Wall is the point in an AI program where the valuable workflow turns out to run on data the security team will not let a model see, and the project shrinks or stops. The crossing is the valuable workflow, and it runs on identifiers. McKinsey's figures are 62% experimenting with agents and 23% scaling them (CX Today, 2026); in regulated work, the second application is where the pilot meets the wall. The design that gets through gives the model the work without a single real identifier.
A desktop agent sees the whole desktop, and Anthropic says to close it near sensitive data
On the employee's machine, ChatGPT Work's Computer Use clicks, types and moves files across applications (PPC Land, 2026). Claude in Chrome takes screenshots of the active tab, and all visible information including personal data becomes part of the context; Anthropic says to avoid opening it while viewing sensitive information (Claude Help Center, 2026).
In a vendor's cloud computer, each OpenAI dot has its own cloud computer and browser (The Next Web, 2026), and the model sees the page in full (OpenAI, 2026). Meta's Muse agent reads the page in full inside its dedicated VM (Meta AI Research, 2026). Isolation governs where data goes, not what the model reads.
| Property | Agent on the employee's machine | Agent in a vendor cloud computer | Agent in a customer-owned governed environment |
|---|---|---|---|
| What the model reads | The screen in full, any tab | The page in full | The task's fields with identifiers as tokens |
| Who holds the keys | The employee's device | The vendor | Your organization |
| Who approves a payment | A setting, often "automatically approve" | Rules and an automated review | A named person, on the record |
One token per identifier lets the model match CLAIMANT_001 across 5 screens
Render-layer tokenization is replacing sensitive values with consistent stand-in tokens at the point where a screen is rendered, before any AI model reads it, so the model works with SSN_001 and ACCT_001 and real values resolve only at approved destinations at the moment of action. The same claimant is the same token on every screen, so the model matches by token.
Masking is the usual answer, and a masked value is gone, so screen one cannot be matched to screen three and someone hands the agent the real value (Masking vs. Tokenizing Data for AI, 2026).
| Property | Masking | Tokenizing at the render layer |
|---|---|---|
| Value on screen one | Hidden, gone | SSN_001 |
| Same value on screen three | Hidden, unmatchable | SSN_001 |
| Model can match the record across systems | No | Yes, by token |
The loss date, the coverage code and the amount stay in clear; names, SSNs, account and card numbers become tokens. This is Least Exposure: the principle that for each piece of work, the AI receives exactly the data the task requires and nothing more, enforced before any model reads the screen.
An allow list is not a tether: Microsoft's documentation says it does not stop the model opening a site
Tethered agent: an agent that works only inside the governed environment a named person connected it to, on the applications that person chose.
You may be relying on an allow list. Copilot Studio's documentation states that its access control "only prevents the model from taking actions on websites or applications that aren't in the allow list. It doesn't stop the model from opening them" (Microsoft Learn, 2026). That governs the action. It does not change what the model reads on a page it reached.
A connector per application is the other route. Each returns the whole object when the task needed two fields, and the application that belongs to another organization has no API you can schedule.
A tethered agent reaches each application through the screen, under the login the named person already holds. Nothing is created for it, and no permission changes; what changes is what the AI can see. A screen outside the per-task policy is one the environment does not render for the model. The run stops, and the named person extends the policy, takes over or ends the run.
Greshake et al. showed in 2023 that an inbound email can carry the agent's next instruction
The crossing reads content you do not control: a supplier page, a database result, an inbound email. Greshake and colleagues showed that content observed on one page can direct what an LLM-integrated application does on the next (Greshake et al., 2023), building on the prompt attacks Perez and Ribeiro catalogued a year earlier (Perez and Ribeiro, 2022). Anthropic reports attack success under 0.08% for Claude in Chrome in internal testing (Claude Help Center, 2026).
0.08% attack success · 1 token per identifier · 1 approval before a real value moves
Under 0.08% is a model control. Plan for the fraction that succeeds: inside a governed environment it collects SSN_001 and ACCT_001, and the consequential action still waits.
Supervised Delegation: a named person grants the access, chooses the applications, confirms what is tokenized, can watch and pause the run, and approves every consequential action, on the record. On approval, the real payee details reach the portal at that moment; the model never holds them. You may have "always allow" on the step that pays. That is where the real value resolves, with no one on the record.
The AI Control Record exports every screen as tokens to your SIEM, not to a vendor's Activity View
AI Control Record: the record of every screen the agent saw as tokens, every action, every approval with a name, exported to the customer's own monitoring. Entry one is the per-task policy the named person confirmed; every screen, action and approval follows it.
A dot's Activity View lets the user follow, redirect or stop work; key holder and data location are not disclosed (OpenAI, 2026). The vendor holds the record; your auditor asks you.
Separation of model and control: the principle that the environment deciding what an AI agent sees and who approves what it does is owned by the customer and independent of whichever model performs the work. The vendor that is the model should not also be the judge of the model. Gartner finds that uniform governance across AI agents will lead to enterprise AI agent failure (Gartner, 2026); the per-task policy is the opposite of uniform. The floor is set by the minimum necessary standard (eCFR, 2026) and FERPA's school official exception, which requires direct control over education records (eCFR, 2026).
6 Rules for securing an agent across applications
Map every application and every hand-off before the agent touches one
List the applications in order, who logs in to each, and which belong to another organization. Mark the consequential actions.
| Column | What goes in it |
|---|---|
| Application | Claims platform, policy system, industry database, portal, mailbox |
| Login | The named person, under existing permissions |
| Consequential action | Payment, submission, posting, record change |
Run the agent in an environment you own, never on the desktop
The employee's machine puts every tab in scope; a vendor cloud computer puts the vendor in the chain of custody.
Test: Ask who can decrypt a screen the agent saw last Tuesday. If the answer names a vendor, the environment is not yours.
Connect each application under the person's existing login
Nothing is created for the agent. Permissions stay exactly as they are; what changes is what the AI can see.
Before: A service account named agent-svc on the claims platform and a connector with payments:write.
After: Each application's access log shows the named person's account. No new identity exists.
Keep one token per identifier for the whole task
The same real value maps to the same token on every screen in the run. Masking breaks the match, and so does a token that changes between screens.
Before: The claimant is masked differently on each screen, and the agent asks a person for the SSN.
After: The claimant is CLAIMANT_001 on all five screens, and the loss database query resolves the real value at that approved destination when the named person approves.
Stop on any screen the policy does not cover
A screen outside the confirmed policy is not rendered for the model. The run stops and the named person decides.
Test: Send the agent to an unlisted screen on purpose. The record shows a stop entry with no action after it.
Make every consequential action wait for the named person
Each waits, on the record. The real value resolves at the destination only on approval.
| Action | Who approves | Where the real value appears |
|---|---|---|
| Payment at the portal | Named person | Portal, on approval |
| Query to the external loss database | Named person | The database, on approval; the model still sees the token |
How to choose where the agent runs
- If at least one application in the task belongs to another organization, choose the screen inside a governed environment; you cannot schedule their API.
- If the task must match one record across three or more applications, choose render-layer tokenization over masking.
- If your current control is a desktop extension with "automatically approve" on, choose a customer-owned environment before expanding the pilot.
- If the vendor cannot say who holds the keys to the computer the agent runs in, choose an environment where the answer is you.
- If a step pays, submits, posts or changes a record, choose Supervised Delegation with a named person, never self-approval.
- If the records fall under the minimum necessary standard, PCI DSS or FERPA, choose the design whose record shows every screen as tokens and every approval with a name.
The checklist
| Check | Pass | Fail |
|---|---|---|
| Count the applications in the task map | All five, actions marked | One, or hand-offs left to a person |
| Find where the agent runs | A customer-owned environment, keys you hold | The desktop or a vendor cloud computer |
| Look for a new identity | None; each app's log shows the named person | A service account or connector for the agent |
| Open the record for one run | Entry one is the confirmed policy with a name | Entry one is a screen |
| Read the first screen in the record | Name, SSN, account only as SSN_001, ACCT_001 | A real identifier in clear |
| Compare the claimant on screens one and three | Same token | A different token, a mask, or the real value |
| Run a detour to an unlisted screen | A stop entry, no action | The screen is read and acted on |
| Reconcile the portal log with the SIEM | Real payee in the portal; ACCT_001 and approval in the SIEM | A payment with no approval entry |
| Inject an instruction on a supplier page in a test | Tokens collected, the action still waited | The action ran |
Questions
Does the agent need a login for each application?
No. It works under the permissions the named person already holds, on the applications that person connected. Nothing is created for it: no service account, no connector, no scope. The applications' own access logs show the person's account. Permissions do not change; what changes is what the AI can see on each screen, which is where a security review should start.
How does the agent match a record across systems if the identifier is tokenized?
By the token. Inside one task, the same real value maps to the same token on every screen, so CLAIM_001 on the claims platform is CLAIM_001 in the industry database result and at the portal. The model never holds the real value; it resolves at the approved destination only at the moment of the approved action, with the named person on the record.
What happens when the agent reaches a screen outside the policy?
The run stops and the named person decides. A screen outside the confirmed policy is one the environment does not render for the model, so there is nothing to act on. The person extends the policy, takes over, or ends the run, and each choice lands in the record with a name. An allow list acts after the page is read.
Can the agent move data from one application to another?
It carries the task's fields and the tokens, not the real identifiers, because it never received them. A query to the external loss database needs the real identifier, so it resolves at that approved destination when the named person approves, and the model still sees the token. The loss date and the amount move in clear because the work runs on them. A payee's real account details reach the payment portal only when the named person approves.
Why not one agent per application?
Because the work is the crossing. Automating each system separately leaves every hand-off manual and slow and re-enters the real identifiers at each one. One agent on all five screens, with one token per identifier and one person approving, automates the task. Five agents on five islands leave the SSN with a person at each boundary, where it leaks today.
Does the agent see the employee's email?
Only the mailbox a named person connected, and only as tokens. An approval thread the workflow needs is in scope, with the sender and any identifiers tokenized. The rest of the inbox and the desktop are outside the environment. An inbound email can carry instructions (Greshake et al., 2023), so it is read as tokens and the consequential action still waits.
Does this satisfy the minimum necessary standard, PCI DSS scope or FERPA?
It is aligned with the minimum necessary standard, because the model receives the task's fields with identifiers as tokens. PCI DSS scope depends on where cardholder data appears; CARD_001 at the model is the question for your assessor. FERPA requires direct control over education records; the record and the named person are what you show. The determination belongs to your counsel and assessor.
Methodology
What this page rests on. Vendor documentation read as of October 9, 2026 and quoted with its date: Microsoft Learn, the Claude Help Center, OpenAI and Meta AI Research. Preprints on indirect prompt injection (Greshake et al., 2023) and prompt attacks (Perez and Ribeiro, 2022). Gartner's May 2026 release, McKinsey's State of AI 2026 via CX Today, and the regulation text cited. The claim and invoice examples are illustrations.
What was not tested. No hands-on testing of the named products was performed; behavior is described from each vendor's published documentation. Platform steps change with releases, and this page carries its date. No specific organization is described.
Whose determination it is. Whether a deployment meets the minimum necessary standard, PCI DSS scope, FERPA's direct control requirement or any other obligation is a determination for the organization's counsel, its assessor, and its security and compliance officers, not this page.
How RedactSure does this
RedactSure runs AI co-workers across an organization's applications inside a governed environment, with no per-application integration and no change to user permissions. The environment is a secure virtual machine in the cloud the customer's posture requires, on hardware-encrypted enclaves, with keys the customer holds; RedactSure holds ciphertext it cannot decrypt.
Every identifier chosen by policy becomes a consistent token at the render layer before any model reads the screen, and the same token holds across every screen in the task, so the agent matches CLAIMANT_001 from claims screen to payment portal without holding the name. The Planner writes the per-task policy; a named person confirms it and approves every payment, submission and record change under Supervised Delegation.
62% experimenting · 23% scaling · 1 named person per agent
Every screen as tokens, every action and every approval with a name lands in the AI Control Record and exports to the customer's own SIEM. The environment is model-agnostic. Deployments are in pilot. The work gets done. The data stays hidden.
Book an AI Agent Security Review →
Further reading
How to Prevent AI Agents From Oversharing Data Between Apps · Should an AI Agent Run in the Employee's Own Browser? · How to Set Up an AI Control Record for AI Agents · What Is the Difference Between Screen-Level Tokenization and API-Level Filtering for AI Agents? · What Is Screen-Level Tokenization? · What data security solutions work without requiring native integrations with every application? · How to secure AI agents? · How to secure AI Agents in Enterprise? · How to protect sensitive information in legacy applications? · How to protect sensitive data across Microsoft and non-Microsoft applications? · How to enforce data protection across multiple enterprise applications?
Sources
Peer-reviewed research and preprints
- Greshake, Kai, et al., "Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection," arXiv:2302.12173, 2023 (preprint; also AISec 2023). https://arxiv.org/abs/2302.12173
- Perez, Fábio, and Ian Ribeiro, "Ignore Previous Prompt: Attack Techniques for Language Models," arXiv:2211.09527, 2022 (preprint). https://arxiv.org/abs/2211.09527
Vendor documentation
- Microsoft Learn, "Automate web and desktop apps with computer use," 2026 (vendor documentation). https://learn.microsoft.com/en-us/microsoft-copilot-studio/computer-use
- Claude Help Center, "Use Claude in Chrome safely," 2026 (vendor documentation). https://support.claude.com/en/articles/12902428-use-claude-in-chrome-safely
- OpenAI, "How we build safety, security and privacy into dots," September 29, 2026 (vendor documentation). https://openai.com/index/how-we-build-safety-security-and-privacy-into-dots/
- Meta AI Research, "How We Built Safety Into Muse," September 2026 (vendor documentation). https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse
Regulation, standards and official guidance
- eCFR, 45 CFR 164.502(b), HIPAA minimum necessary standard, 2026 (regulation). https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.502
- eCFR, 34 CFR 99.31(a)(1)(i)(B), FERPA school official exception, 2026 (regulation). https://www.ecfr.gov/current/title-34/subtitle-A/part-99/subpart-D/section-99.31
Industry analysis and press
- Gartner, "Gartner Says Applying Uniform Governance Across AI Agents Will Lead to Enterprise AI Agent Failure," press release, May 26, 2026 (industry analysis). https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure
- CX Today, "McKinsey's State of AI: The Scaling Gap Is Now CX's Problem," 2026 (press). https://www.cxtoday.com/ai-automation-in-cx/mckinseys-state-of-ai-the-scaling-gap-is-now-cxs-problem/
- PPC Land, "OpenAI kills Atlas browser, folds it into new ChatGPT Work agent," July 2026 (press). https://ppc.land/openai-kills-atlas-browser-folds-it-into-new-chatgpt-work-agent/
- The Next Web, "OpenAI launches dots, always-on AI agents with their own cloud computers," September 29, 2026 (press). https://thenextweb.com/news/openai-dots-always-on-ai-agents-cloud-computers-devday
RedactSure documents
- RedactSure Research, "What Is Render-Layer Tokenization?" (2026). https://redactsure.com/research/what-is-render-layer-tokenization
- RedactSure Research, "What Is a Tethered Agent?" (2026). https://redactsure.com/research/what-is-a-tethered-agent
- RedactSure Research, "What Is Supervised Delegation?" (2026). https://redactsure.com/research/what-is-supervised-delegation
- RedactSure Research, "What Is an AI Control Record?" (2026). https://redactsure.com/research/what-is-an-ai-control-record
- RedactSure Research, "Masking vs. Tokenizing Data for AI" (2026). https://redactsure.com/research/masking-vs-tokenizing-data-for-ai
- RedactSure Research, "What Is Least Exposure?" (2026). https://redactsure.com/research/what-is-least-exposure
- RedactSure Research, "What Is the PII Wall?" (2026). https://redactsure.com/research/what-is-the-pii-wall
- RedactSure Research, "Should the AI Agent Environment Belong to the Model Vendor?" (2026). https://redactsure.com/research/should-ai-agent-environment-belong-to-model-vendor
- RedactSure, "Secure AI That Crosses Every Silo" (2026). https://redactsure.com/blog/secure-ai-that-crosses-every-silo/
- Product behavior described on this page reflects current published designs. Microsoft and Copilot Studio are trademarks of Microsoft Corporation; Claude is a trademark of Anthropic, PBC; OpenAI, ChatGPT and dots are trademarks of OpenAI; Meta and Muse are trademarks of Meta Platforms, Inc.; named to identify the products. Compliance determinations belong to the organization's counsel.
How to Prevent AI Agents From Oversharing Data Between Apps
Review Prevent AI Agents From Oversharing Data Between Apps, with AI agent security, tokenization and approval checks for sensitive enterprise workflows.
Should an AI Agent Use the Employee's Own Browser?
Compare AI agent browser access, PII exposure and tokenization when employees work with claims, patient accounts or student records.
How to Set Up an AI Control Record for AI Agents
Review Set Up an AI Control Record for AI Agents, with AI agent security, tokenization and approval checks for sensitive enterprise workflows.
Screen-Level Tokenization vs API Filtering for AI Agents
Review Screen-Level Tokenization vs API Filtering for AI Agents for AI agents, including tokenization, sensitive data exposure and human approval records.
What Is Screen-Level Tokenization?
Review Screen-Level Tokenization, with AI agent security, tokenization and approval checks for sensitive enterprise workflows.
What Data Security Works Without Native App Integrations?
Review What Data Security Works Without Native App Integrations for AI agents, including tokenization, sensitive data exposure and human approval records.
How to secure AI agents?
Review secure AI agents for AI agent security, with practical checks on sensitive data, tokenization and named human approvals.
How to secure AI Agents in Enterprise?
Review secure AI Agents in Enterprise, with AI agent security, tokenization and approval checks for sensitive enterprise workflows.
How to protect sensitive information in legacy applications?
Review protect sensitive information in legacy applications, with AI agent security, tokenization and approval checks for sensitive enterprise workflows.
How to Protect Data Across Microsoft and Other Apps?
Review Protect Data Across Microsoft and Other Apps, with AI agent security, tokenization and approval checks for sensitive enterprise workflows.
How to Enforce Data Protection Across Enterprise Apps?
Review Enforce Data Protection Across Enterprise Apps, with AI agent security, tokenization and approval checks for sensitive enterprise workflows.
What Is Render-Layer Tokenization?
Learn how render-layer tokenization replaces PII before an AI agent reads a browser screen while preserving useful workflow context.
What Is a Tethered Agent?
Learn how a tethered AI agent stays tied to a named person, with tokenization, bounded permissions and approval for sensitive payments.
What Is Supervised Delegation?
Explore supervised delegation for AI agents in billing and claims, with named responsibility, tokenization policies and human approvals.
What Is an AI Control Record?
Explore an AI agent control record for billing and claims, linking permissions, tokenization decisions, approvals and audit evidence.
How Do Data Masking and AI Tokenization Differ?
Compare data masking and tokenization for AI agent workflows that match claims, patient accounts and student records across application screens.
What Is Least Exposure?
Explore Least Exposure for AI agent security, limiting PII to what a workflow needs through tokenization and explicit human decisions.
What Is the PII Wall?
Explore why PII exposure stalls AI agent projects in claims, patient accounts and student records, and what a governed workflow requires.
Should the AI Model Vendor Own the Agent Environment?
Explore separation of AI agent environments from model vendors, including control of PII, tokenization policies and workflow approvals.
Secure AI That Crosses Every Silo
Explore AI agents that work across billing, collections and enterprise systems while tokenization protects PII at each workflow step.
Bring your hardest questions.
Bring one sensitive workflow and the decisions your team needs to keep in its hands.
Book a demoAbout the author
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.