Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does Sandboxing UiPath AI Agents Protect Sensitive Workflows?

Only partly, because UiPath's serverless runtime isolates where an agent executes, not what the agent sees: secrets arrive as environment variables, live production data is read in full, and PII masking is pattern-based and restores real values on the way out. Check the data path through the sandbox, not the sandbox itself.

Data streams pass through an open sandbox and continue beyond its boundaries as small token-like shapes.

Only partly, because UiPath's serverless runtime isolates where an agent executes, not what the agent sees: secrets arrive as environment variables, live production data is read in full, and PII masking is pattern-based and restores real values on the way out. Check the data path through the sandbox, not the sandbox itself. UiPath's user guide states that the runtime executes the agent in a secure, serverless environment, and leaves the isolation details undescribed (UiPath, 2026). A sandbox of that kind answers a real question, whether a misbehaving agent can damage the host or reach a neighbor's process, and it is a question worth answering. It is not the question most organizations mean when they ask whether a sensitive workflow is protected. That question is about the claims file, the payroll record or the customer account the agent was asked to work on, and those pass through the sandbox by design. A boundary around the runtime says nothing about what crosses the boundary, which is the distinction a governed AI workflow is built to address. This page separates what a serverless sandbox isolates from what it leaves open, traces how sensitive data reaches the agent, sets out what UiPath's documented guardrails and masking cover, shows where pattern-based masking leaves a claims workflow exposed, describes how to measure what crosses the boundary, and lists the claims a buyer should refuse.

Key findings

  • UiPath documents that its runtime executes agents in a secure, serverless environment, while the isolation mechanism, tenancy model and what the environment prevents are not described in the pages reviewed (UiPath, 2026).
  • A coded agent is deployed as a UiPath process within Orchestrator folders and receives its secrets as environment variables, which means credentials are inside the sandbox with the agent rather than kept outside it (UiPath, 2026).
  • In-flight PII masking in the AI Trust Layer detects and replaces PII entities with contextual placeholders before the model sees them and then restores the real values in the response, so protection covers the model call and ends at the response (UiPath, 2026).
  • Tool guardrails are documented as deterministic controls on tool calls that can block, escalate to a user, filter fields or log, which makes them an action control rather than a data visibility control (UiPath, 2026).
  • Container isolation guidance from NIST treats the boundary around a workload and the protection of the data the workload handles as separate concerns, each needing its own controls (NIST, 2017).
  • An agent that holds production credentials and reads production records in full has the excessive agency profile OWASP describes, whatever runtime it executes in (OWASP, 2025).

What does a serverless sandbox isolate, and what does it leave open?

Start with what the word covers. A sandbox is an execution boundary: a process, container or function runs with a restricted view of the host, limited network reach and no persistence beyond the run. UiPath's documentation describes its agent runtime in those terms, a secure, serverless environment in which the agent executes, without describing the isolation technology, the tenancy model or the specific threats the environment addresses (UiPath, 2026). The absence is not unusual; vendors rarely publish isolation internals. It does mean a buyer should read "secure, serverless" as a category of control, not a specification.

What the category protects against is well understood. NIST's container security guide frames the risks of a containerized workload as image, registry, orchestrator, container runtime and host risks, and treats data protection as a matter the workload's own design must address rather than something the container boundary supplies (NIST, 2017). Translated to an agent: the sandbox makes it harder for a compromised or confused agent to alter the host, reach another tenant's process or leave a persistent foothold. Those are escape and persistence threats.

What the sandbox leaves open is everything the agent was given on purpose. Consider a single record type, an insurance claims screen: claimant name, date of birth, policy number, bank account for settlement, adjuster notes. An agent asked to triage the claim must read that screen, and the sandbox delivers it intact, because delivering it is the agent's job. The boundary around the runtime is irrelevant to whether the model reads the bank account number. That is the structural reason the title question cannot be answered yes. The protection is real and it is aimed at a different threat.

How does sensitive data reach a UiPath agent inside the sandbox?

Through two paths, both documented. The first is credentials. UiPath's guide to coded agents states that a coded agent is deployed as a UiPath process within Orchestrator folders, and that secrets reach it as environment variables (UiPath, 2026). Environment variables are a standard mechanism and a weak one for secrets: anything running inside the sandbox can read them, including the agent's own code and whatever that code is persuaded to do. The sandbox encloses the agent and its credentials together.

The second path is the data the task requires. Agents that triage claims, reconcile invoices or update employee records read live production data through the tools they are given. UiPath's guardrail documentation describes operators using guardrails to keep agents in alignment with organizational policies, and does not describe the data types the guardrails cover (UiPath, 2026). The July 2026 release notes describe sequential tool processing for more stable handling of guardrails and routing for human-in-the-loop escalation (UiPath, 2026). Both improve how actions are controlled. Neither changes what the model reads before it decides.

Put the two paths together on the claims screen. The agent holds the claims system credential in its environment, calls the tool that opens the claim, and receives every field. If the adjuster notes contain an instruction planted by a claimant, the agent reads that too, with the credential in hand. OWASP's excessive agency entry describes this combination, broad permissions plus broad data plus autonomy, as the condition under which a manipulated agent causes harm, and the sandbox alters none of the three terms (OWASP, 2025).

What do UiPath's documented guardrails and PII masking cover?

UiPath documents three controls closer to the data than the sandbox. Tool guardrails control unexpected behaviors within tool calls deterministically, with outcomes of block, escalate to a user, filter fields or log (UiPath, 2026). Instance-level guardrail management keeps agents aligned with organizational policies. And in-flight PII masking in the AI Trust Layer detects and replaces PII entities with contextual placeholders before the model call, then restores the values in the response (UiPath, 2026).

Dimension UiPath, per its documentation What a buyer should verify
Runtime isolation Agents execute in a secure, serverless environment Isolation technology, tenancy, and the threats it addresses
Credential handling Secrets reach coded agents as environment variables Whether a prompt-injected agent can read and exfiltrate them
Tool guardrails Deterministic: block, escalate, filter fields, log Which tools are covered and who can edit the rules
Guardrail scope Keep agents aligned with organizational policies Data types covered: not described in the pages reviewed
PII masking Detects PII entities, substitutes placeholders, restores values in response Entity list, detection method, and where restored values land
Escalation Human-in-the-loop routing (July 2026) Which actions escalate by default and what the approver sees

Guardrails operate at the tool call, after the model has reasoned and decided. The field filter is the one outcome that narrows what a tool returns; its granularity and defaults are not described in the pages reviewed. PII masking operates before the model call and ends at the response, where restored values appear in logs, downstream tools and outputs. None of the three is described as covering the environment variables holding credentials.

Where does pattern-based masking leave a claims workflow exposed?

Masking that detects PII entities depends on recognizing them. UiPath's documentation describes the AI Trust Layer identifying PII entities and substituting contextual placeholders (UiPath, 2026). The entity list, the detection method and the handling of values that match no pattern are not described in the pages reviewed. The design pattern itself, shared by most in-flight masking products, has three gaps on a claims screen.

First, values that are sensitive without being PII patterns. A policy number is an internal identifier whose format varies by carrier and product line; a claim reserve amount is a number; an adjuster's note that the claimant is under investigation is prose. None fits a social security number or email regex, and all three are confidential. Second, restoration. Masking that restores real values in the response puts them back into whatever the agent does next: a ticket, a summary, a downstream tool. The protection covers the model call and nothing after it. Third, the credential path. Secrets delivered as environment variables are not in the prompt, so prompt-side masking has no view of them.

Guardrails help with the consequences of the third gap, because a tool call that attempts to send data somewhere unexpected can be blocked or escalated. They do not address the first two, since a guardrail evaluates the action, not what the model learned on the way to it. For a claims workflow, the sandbox protects the host, masking protects recognized identifiers during the model call, and the policy number, reserve amount and investigation note travel the whole path in clear. Research programs on trustworthy agent automation treat this layering problem, the gap between isolating execution and governing what the agent reads and does, as the open infrastructure question (Columbia University DAPLab, 2026).

How should an organization measure what crosses the sandbox boundary?

Instrument the data path rather than the runtime. Pick one real workflow, the claims triage above or an equivalent, and record three things for a single run. First, the full prompt and context delivered to the model at each step, captured from the model gateway or the trace, with masked placeholders visible. Compare that capture against the source screen and list every confidential value that reached the model unmasked. Second, every tool call's inputs and outputs, including the fields a guardrail filtered. Third, the environment the agent ran in: which variables were set, and whether any tool call or log line could have exposed them.

The first measurement answers the masking question with a count rather than an assurance. If the policy number, reserve amount and free-text notes reached the model in clear, the pattern-based layer covered the identifiers it was built for and nothing else, and that is the figure for the risk committee. The NIST AI Risk Management Framework's Measure function asks for metrics chosen for the organization's own context, and a per-field exposure count on a real screen is that kind of metric (NIST, 2023). The third measurement tests the credential path; a secret in an environment variable is one successful injection away from a tool call that reads it.

Repeat the run with a planted instruction in a free-text field and watch which guardrail fires, whether escalation reaches a named person, and what that person sees. The test shows whether the approver can see the real values the agent acted on, or only the restored output. Zero trust guidance applies: evaluate each access at the point of use rather than trusting the boundary the request came from (NIST, 2020). A sandbox is such a boundary.

What does a governed environment change?

A governed environment changes the data path through the sandbox rather than the sandbox itself: the claims record reaches the model as consistent tokens, real values resolve only when an approved action completes, and the protection does not end at the model's response. UiPath's runtime executes the agent in a secure serverless environment (UiPath, 2026); NIST treats the workload boundary and the protection of the data it handles as separate concerns (NIST, 2017). This class of control supplies the second.

The mechanism acts on the rendered screen. Sensitive values, the odd-format policy number, the reserve figure, the adjuster's note, are replaced with consistent tokens before any model reads the page, so the task runs on tokens. Real values resolve only at an approved destination at the moment of an approved action, such as a payment released. A named person confirms what is tokenized and approves consequential actions. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

Two points mark the difference from the documented guardrails. In-flight PII masking detects entities by pattern and restores real values in the response (UiPath, 2026), so an unmatched value reaches the model and every value returns on the way out; tokenization at the screen resolves at the destination, not in the response. Tool guardrails act after the model has reasoned; approval here sits in front of the action.

The environment does not alter the serverless runtime, Orchestrator folders or the model, and it covers the rendered page rather than environment variables or the filesystem inside the sandbox.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. Where a sandbox draws a boundary around the runtime and lets the data pass through it, RedactSure's design governs the data path itself. Work runs in a governed environment in the customer's cloud. Substitution happens at the render layer before any model reads the screen, so the policy number, bank account and claimant identifier on a claims screen appear to the model as consistent tokens such as ACCT_001 or PATIENT_001 for the whole run, by policy rather than by pattern match. Real values resolve only at approved destinations at the moment of an approved action, so nothing is restored into a summary or a downstream tool. A named person confirms the tokenization policy and approves every payment, submission and record change, a model RedactSure calls Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own claims or payables workflow would show, field by field, which values a sandboxed agent would have read in clear and which the model saw as tokens instead, with the AI Control Record as the evidence. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on UiPath's published documentation for Agents on Automation Cloud: the user guide pages on running agents and on coded agents, the tool guardrails and guardrail management pages, the AI Trust Layer PII masking page in the admin guide, and the July 2026 release notes. It draws on NIST Special Publication 800-190 on application container security, NIST Special Publication 800-207 on zero trust architecture and the NIST AI Risk Management Framework (official guidance), on OWASP's Top 10 for LLM Applications entry on excessive agency (industry standard), and on the Columbia University DAPLab program on infrastructure for trustworthy agent automation (research program). All sources were read as of October 16, 2026. One UiPath page was read in its German edition and the quoted phrase is translated.

No hands-on testing of UiPath or any other named product was performed. Where this page says a capability is not described in the pages reviewed, it means the specific documentation pages listed below do not describe it, which is not a statement that the capability is absent. Vendor features change, as the July 2026 release notes show, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The claims screen, invoice and employee record examples describe record types, not any organization; no customer or prospect is described.

Whether a given UiPath deployment, its runtime configuration, its guardrails and its masking settings meet an organization's obligations for the data in its workflows is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

UiPath's documentation describes a serverless runtime that executes agents in a secure environment, coded agents that receive secrets as environment variables, deterministic guardrails on tool calls, and in-flight PII masking that substitutes placeholders before the model call and restores real values in the response. Read together, those statements locate the protection precisely: the sandbox guards the host, the guardrails guard the action, and the masking guards recognized identifiers for the duration of one model call. The sensitive workflow, the claims file with its odd-format policy number, its reserve amount and its free-text notes, passes through all three in clear, with the credential alongside it. Whether a render-layer design of the kind RedactSure describes closes that gap is a question for a pilot. The test is to name one agent and one task, capture what the model received at each step, and count the confidential values that arrived unmasked.

Frequently asked questions

What does UiPath's serverless sandbox actually protect?

UiPath's user guide states that the runtime executes the agent in a secure, serverless environment, without describing the isolation technology or tenancy model. A control of that kind protects the host and neighboring workloads from the agent: it limits what a misbehaving or manipulated agent can alter, reach or leave behind. It does not change what the agent reads, because the data the task requires is delivered into the sandbox on purpose. Escape and persistence are the threats a sandbox addresses.

Where do a UiPath agent's credentials live at runtime?

The documentation for coded agents states that the agent is deployed as a UiPath process within Orchestrator folders and that secrets reach it as environment variables. That places the credential inside the sandbox with the agent. Anything the agent's code does, including what it is persuaded to do by an instruction planted in a record it reads, runs with those variables available. A buyer should ask what inside the runtime can read them and whether a tool call could carry them out.

Does UiPath's PII masking protect sensitive data in a workflow?

It protects recognized PII entities during the model call. The AI Trust Layer documentation describes in-flight masking that detects PII entities, replaces them with contextual placeholders before the model sees them, and restores the real values in the response. Values that match no pattern, such as internal identifiers, amounts and free-text notes, are not described as covered, and restoration means the real values appear in whatever the agent produces next. The entity list and detection method are not described in the pages reviewed.

Are UiPath guardrails a data protection control?

They are an action control. The tool guardrails documentation describes deterministic rules on tool calls with four outcomes: block, escalate to a user, filter fields or log. The field filter narrows what a tool returns; the others govern whether and how an action proceeds. Guardrails evaluate the call after the model has reasoned, so they do not change what the model read. Which data types guardrails cover is not described in the pages reviewed.

Does human-in-the-loop escalation make the workflow safe?

It makes consequential actions reviewable, which is valuable and different from making data safe. The July 2026 release notes describe escalation routing to a person. The question a buyer should test is what that person sees: if the escalation screen shows restored real values, the reviewer is handling the sensitive data the masking was meant to protect, and if it shows only the agent's proposed action, the reviewer may be approving on incomplete information. Both outcomes should be observed in a pilot.

How should a buyer test a sandboxed agent on a sensitive workflow?

Run one real workflow and capture the prompt and context delivered to the model at each step, every tool call's inputs and outputs, and the environment the agent ran in. Count the confidential values that reached the model unmasked, field by field. Then repeat with a planted instruction in a free-text field and observe which guardrail fires and what the escalation shows. The counts, not the sandbox description, answer whether the workflow was protected on that date.

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.