Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do You Control Data Access for Kore.ai Agents?

Through three documented layers: workspace role-based access, pre-deployed input and output guardrails, and regex-based PII masking that redacts matching values before the agent processes them. Check how the regex patterns hold up against the format variations Kore.ai's own documentation warns about, and who in the workspace can change auth profiles.

Application records pass through successive role, filtering and control layers before reaching a geometric processing node.

Through three documented layers: workspace role-based access, pre-deployed input and output guardrails, and regex-based PII masking that redacts matching values before the agent processes them. Check how the regex patterns hold up against the format variations Kore.ai's own documentation warns about, and who in the workspace can change auth profiles. Kore.ai's documentation describes role-based access that controls what users can do across the platform, with models, auth profiles and environments scoped to a workspace (Kore.ai, 2026). Its guardrails page describes pre-deployed scanners on agent inputs and outputs, with a separate PII layer that masks names, emails and phone numbers before the agent processes them (Kore.ai, 2026). The practical problem is the one the documentation itself flags: regex patterns must account for format variations (Kore.ai, 2026). A control that recognizes a phone number written one way and misses it written another has coverage that is a property of the data, not of the policy, the limitation AI agent access control beyond traditional IAM is meant to address. This page sets out the three layers, how regex masking behaves when formats vary, what guardrails catch, who can change auth profiles, how to measure data access for a deployment, and which claims a buyer should refuse.

Key findings

  • Kore.ai's administration documentation describes role-based access that controls what users can do across the platform, with models, auth profiles and environments workspace-specific, so an agent's reach is decided by whoever holds workspace rights (Kore.ai, 2026).
  • Guardrails are documented as pre-deployed scanners that evaluate agent inputs and outputs, and a separate PII layer masks names, emails and phone numbers before the agent processes them (Kore.ai, 2026).
  • The masking is pattern-based: any end-user input that matches the PII pattern is redacted by the platform, including in chat logs, and the safety guide states that regex patterns must account for format variations (Kore.ai, 2026; Kore.ai, 2026).
  • Pattern-based redaction is the content-inspection approach NIST's glossary describes under data loss prevention, and it inherits that approach's dependence on recognizing what it is looking for (NIST, 2026).
  • Across the thirty deployed agent systems the 2025 AI Agent Index documented, most developers share little information about safety and evaluations, so a buyer should expect to establish masking coverage by testing rather than by reading (Staufer et al., 2026).
  • Input that evades a pattern and carries an instruction is the prompt injection case OWASP ranks first among LLM application risks, and output guardrails are the last check before it takes effect (OWASP, 2025).

What are the three control layers Kore.ai documents?

The first is administrative. The settings console provides role-based access to control what users can do across the platform, and models, auth profiles and environments are specific to a workspace (Kore.ai, 2026). An auth profile is the credential an agent uses to reach an external system; a model is the LLM it calls; an environment is where it runs. The people with rights in a workspace decide what its agents connect to and as whom.

The second is the guardrail layer. Kore.ai describes guardrails as pre-deployed scanners that evaluate agent inputs and outputs (Kore.ai, 2026). They sit on either side of the model: an input scanner examines what arrives before the model reasons, an output scanner examines what the model produced before it is returned or acted on. Scanner categories and thresholds are not described in the pages reviewed.

The third is the PII layer, documented separately from guardrails. It masks names, emails and phone numbers before the agent processes them, and the developer documentation states that any end-user input matching the PII pattern is redacted by the platform, including in chat logs (Kore.ai, 2026). Consider a single record type, a customer account screen in a support workflow: account number, customer name, phone, email, postal address, balance and the agent notes from previous calls. Layer one decides whether the agent can reach the account system at all and as whom. Layer three decides which of the values on that screen are replaced before the model sees them. Layer two decides whether what arrives and what leaves trips a scanner. None of the three is a statement about which fields on the screen the agent should see for this task.

How does regex-based PII masking behave when formats vary?

It covers what matches. Kore.ai's safety guide states the limitation: regex patterns must account for format variations (Kore.ai, 2026). A pattern written for a ten-digit phone number with hyphens will not match the same number with spaces, parentheses or a country code unless it anticipates each variant. Email addresses have a stable structure; phone numbers have dozens of national formats; names have no format, and a regex for names is a list, not a pattern.

Dimension Kore.ai, per its documentation What a buyer should verify
Masking method End-user input matching the PII pattern is redacted, including in chat logs The pattern set in use and the formats each covers
Entities named Names, emails and phone numbers Whether account numbers, addresses and free text are covered
Format sensitivity Regex patterns must account for format variations Detection rate on the organization's own data as customers type it
Scope of masking End-user input Whether retrieved values are masked on the same basis
Access administration Role-based; models, auth profiles and environments are workspace-specific Which roles can change an auth profile

On the customer account screen, the pattern layer as documented addresses three of seven fields. The account number is not a named entity and its format is specific to the organization. The address and balance are not named. The notes are free text, where a previous agent may have written the phone number with spaces, the account number with a typo, or a fraud flag that matches nothing. The developer documentation describes masking of end-user input; whether values retrieved from a connected account system are masked on the same basis is not described in the pages reviewed. That question decides whether the layer protects the screen or only the chat.

What do input and output guardrails catch, and what passes through?

Guardrails are scanners, and a scanner catches what it is built to recognize. Kore.ai documents them as pre-deployed and positioned on inputs and outputs; the categories are not described in the pages reviewed. In the product category generally, input scanners look for prompt injection attempts, jailbreak patterns and disallowed topics, and output scanners look for toxicity, leakage of system instructions and sometimes PII in the response. Each is a classification decision made on text, with the detection and false positive rates that classification implies.

Two things pass through a scanner by design. The first is legitimate data the task requires. An agent asked to confirm a customer's address needs the address, so an output scanner that let addresses through is working as intended, and the question of whether the model should have seen the address at all was decided upstream. The second is content that does not resemble what the scanner was trained or configured to find. Prompt injection research shows that instructions can be carried in text that looks nothing like an attack, which is why OWASP lists injection first and treats input filtering as one defense among several rather than a sufficient one (OWASP, 2025).

The combination with the previous layer matters. An instruction in the agent notes field that evades the input scanner is read by the model alongside whatever the PII layer left unmasked, and the model acts with whatever the auth profile permits. OWASP's excessive agency entry describes that chain, broad data plus a credential plus autonomy, as the setting in which a scanner miss becomes a consequential action (OWASP, 2025). Output guardrails are the last check before the action. The layers before them decide how much they have to catch.

Who can change auth profiles and models, and why does that decide data access?

Because the auth profile is the agent's identity in every connected system, and the model is where the data goes. Kore.ai's documentation makes both workspace-specific and places them under role-based access (Kore.ai, 2026). A person with rights to edit an auth profile can swap the credential an agent uses to reach the account system for one with broader read, or point it at a different system entirely. A person with rights to change the model can route every unmasked field on the screen to a different provider. Neither change is visible to the end user, and whether either triggers an approval or a log entry reviewed by someone else is not described in the pages reviewed.

This is the sense in which role-based access is a data access control: it is a control on the controllers. The useful questions are how many people hold the roles that can change auth profiles and models in each workspace, whether those roles are separated from the roles that build agents, and what record exists of each change. The answers vary by deployment and are not documented at the platform level in the pages reviewed; they are properties of the organization's configuration. AI agent tool access frames the same question for any platform: which systems an agent can use is decided by whoever can edit its connections, so that group is the control surface.

The commercial context is worth one sentence. Kore.ai secured a strategic growth investment led by AllianceBernstein Private Credit Investors in January 2026 (ChannelLife, 2026), which signals a platform that will keep adding capabilities. Each new capability arrives with its own defaults, and the roles that govern auth profiles today will govern whatever is added next.

How should an organization measure data access for its own Kore.ai agents?

Test the pattern layer on real formats first. Assemble a sample of the organization's own customer data as it is actually written: phone numbers as customers type them, account numbers in the organization's format, names from the real distribution, addresses, and a set of free-text notes drawn from past interactions. Run it through the PII layer and count what was masked and what was not, field by field. The result is a detection rate on the organization's data rather than on the vendor's examples, and it is the figure the safety guide's warning about format variations asks for.

Then trace the screen. For one agent and one account record, capture what the model received, if the platform exposes the prompt or trace, and compare it with the source record. Mark each field as masked, unmasked or absent. If the platform does not expose what the model received, the measurement has to be inferred from outputs, and that limitation belongs in the record. Then run the injection test: place an instruction in the notes field, observe whether the input scanner fires, and if it does not, observe what the agent attempted under its auth profile.

Finally, audit the roles. List every person with rights to change auth profiles, models or environments in each workspace, and check whether a change log exists and who reads it. The NIST AI Risk Management Framework's Measure function asks for metrics chosen for the organization's own context, and a per-field detection rate, a per-screen exposure trace and a role list are three such metrics (NIST, 2023). None of them can be read from documentation. Each takes an afternoon with the organization's own data.

What does a governed environment change?

A governed environment moves the data decision from a pattern that must recognize a value to a policy that names which fields on a screen the model may receive, and it leaves a record of what was tokenized on every run.

The mechanism is a class of control that sits in front of whatever agent platform is in use. Sensitive values on the rendered screen are replaced with consistent tokens before any model reads them, so the task runs on tokens. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized for each workflow and approves consequential actions such as payments, submissions and record changes. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

This answers the open points on this page. Kore.ai's masking covers names, emails and phone numbers by pattern, and its safety guide states that regex patterns must account for format variations (Kore.ai, 2026); a field chosen by policy on a screen is tokenized whatever format the value takes, so the detection rate test the page asks for applies to a smaller set of values. Pattern-based redaction is the content-inspection approach NIST describes under data loss prevention (NIST, 2026), and this class of control sits above it rather than replacing it. The question of who can change an auth profile becomes one of record: a change made by an agent in the environment is an action a named person approved, and the approval is exported.

The environment does not change the platform's roles, guardrails or masking, which continue to apply to end-user input; it covers what the model receives from a rendered screen.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. Where a pattern layer masks what a regex recognizes and leaves the rest of the screen to the model, RedactSure's design substitutes by policy rather than by pattern. 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 account number, phone number, name and notes on a customer account screen appear to the model as consistent tokens such as ACCT_001 or PATIENT_001 for the whole run, whatever format the value was written in. Real values resolve only at approved destinations at the moment of an approved action. 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 support or account-servicing workflow would show, field by field and in the organization's own formats, which values a pattern-based layer would have passed to the model 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 Kore.ai's published documentation: the Agent Platform administration overview, the PII and guardrails settings page, the safety and guardrails guide, and the developer documentation on PII and sensitive data anonymization. It draws on the 2025 AI Agent Index preprint by Staufer and colleagues (preprint), on OWASP's Top 10 for LLM Applications entries on prompt injection and excessive agency (industry standards), on the NIST Computer Security Resource Center glossary entry for data loss prevention and the NIST AI Risk Management Framework (official guidance), and on a January 2026 press report of Kore.ai's funding (industry press). All sources were read as of October 16, 2026.

No hands-on testing of Kore.ai or any other named product was performed. Where this page says a capability is not described in the pages reviewed, it means the specific pages listed below do not describe it, which is not a statement that the capability is absent; the guardrail scanner categories and the treatment of retrieved data by the PII layer are the main such items. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The customer account screen and support workflow examples describe record types, not any organization; no customer or prospect is described.

Whether a given Kore.ai deployment, its workspace roles, its guardrail configuration and its masking patterns meet an organization's obligations for the data its agents handle is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

Kore.ai documents three layers for controlling what its agents reach: role-based access over workspace-specific models, auth profiles and environments; pre-deployed guardrail scanners on inputs and outputs; and a PII layer that redacts names, emails and phone numbers matching a pattern before the agent processes them, including in chat logs. The documentation also states that regex patterns must account for format variations, which places the coverage of the masking layer in the hands of whoever writes and maintains the patterns, and makes it a property of the data's formatting rather than of the policy. Role-based access decides who can change the identity and the model behind an agent. A render-layer design of the kind RedactSure describes substitutes by policy rather than by pattern. The test is to name one agent and one task, run the organization's own customer data through the PII layer in the formats customers actually use, and count what came through unmasked.

Frequently asked questions

What does Kore.ai's PII masking actually cover?

Names, emails and phone numbers, according to the guardrails settings page, masked before the agent processes them. The developer documentation describes the mechanism as pattern matching: any end-user input that matches the PII pattern is redacted, including in chat logs. Account numbers, addresses and free text are not among the named entities. The safety guide states that regex patterns must account for format variations, so coverage depends on how each pattern was written and how the data is formatted.

Are Kore.ai guardrails the same thing as PII masking?

No. The documentation describes guardrails as pre-deployed scanners that evaluate agent inputs and outputs, and describes the PII layer separately as masking specific entities before processing. Guardrails classify text for categories such as injection or disallowed content; the PII layer substitutes matching values. Both operate on text passing through the agent. Neither is described as deciding which fields of a connected system's record the agent should be permitted to see for a given task.

Does the masking apply to data the agent retrieves from other systems?

The developer documentation describes redaction of end-user input, including in chat logs. Whether values the agent retrieves from a connected account or ticketing system are masked on the same basis before the model reads them is not described in the pages reviewed. This decides whether the layer protects a customer account screen or only what the customer typed, and a buyer should test it by tracing one record through one agent.

Who controls which systems a Kore.ai agent can reach?

Whoever holds the workspace roles that can edit auth profiles, models and environments. Kore.ai's administration documentation describes role-based access that controls what users can do across the platform, with those three objects being workspace-specific. An auth profile is the agent's credential in a connected system, so the people who can change it decide the agent's reach. The number of such people, and whether changes are logged and reviewed, are properties of each deployment's configuration.

How do format variations defeat regex-based masking?

A regex matches a specified shape. A phone number written with hyphens, spaces, parentheses, a country code or no separators is five shapes, and a pattern covers only the ones it was written for. Account numbers vary by organization, names have no shape at all, and free-text notes can carry any of these in any form. Kore.ai's safety guide states that patterns must account for format variations, which is a statement that coverage is the implementer's responsibility and is only as good as the pattern set.

How should an organization test Kore.ai's data controls before deployment?

Run a sample of the organization's own customer data, formatted as customers actually write it, through the PII layer and count what was masked field by field. Trace one record through one agent and compare what the model received with the source. Plant an instruction in a notes field and observe the scanner and the agent's attempted action. List everyone who can change auth profiles. A governed environment that tokenizes by policy at the render layer, as RedactSure's design does, replaces the first test with a policy confirmation.

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.