Skip to content
redactsure
Book a demo

Explore.

Comparison · By Chris Sowa · Published
Last updated

What Is the Difference Between RedactSure and Arthur AI for AI Agent Runtime Controls?

Arthur AI documents a self-hosted evaluation and guardrails engine that blocks or flags bad prompts and responses for LLM applications. RedactSure decides what an AI agent sees before the model reads the screen and holds each consequential action for a named person. Treating one as the other leaves exposure or action ungoverned.

Browser tokens enter an isolated layered model and an action barrier beside an activity file.

Arthur AI documents a self-hosted evaluation and guardrails engine that blocks or flags bad prompts and responses for LLM applications. RedactSure decides what an AI agent sees before the model reads the screen and holds each consequential action for a named person. Treating one as the other leaves exposure or action ungoverned. Runtime controls for agents answer two separate questions. The first is quality and safety of what a model says: is the prompt hostile, is the response acceptable, is the application drifting in production. The second is exposure and authority: what data the model is allowed to read for this piece of work, and who signs off before the agent changes a record or moves money. Least Exposure belongs to the second question, and a buyer who files both questions under "guardrails" can end up with a strong answer to one and no answer to the other. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • Arthur AI describes the Arthur Engine as "a self-hosted evaluation and guardrails engine for LLM applications," with real-time guardrails, asynchronous LLM-as-a-judge evaluators, continuous production monitoring, RAG evaluation, prompt management, transforms and agent evaluations (Arthur AI, 2026).
  • The same page says guardrails "block or flag bad prompts and responses"; the page reviewed does not state whether the engine detects, redacts, masks or tokenizes sensitive data (Arthur AI, 2026).
  • OWASP lists prompt injection (LLM01) and sensitive information disclosure (LLM02) as separate risks in its 2025 Top 10 for LLM applications (OWASP, 2025; OWASP, 2025).
  • Indirect prompt injection arrives through content the model reads, such as web pages and documents, rather than through the user's prompt (Greshake et al., 2023).
  • A model-agnostic Tool-Input Firewall that strips data a tool call does not need, paired with an output sanitizer, reached about 0 percent attack success with little utility loss on four public agent benchmarks, and the same authors warn those benchmarks are easily saturated (Bhagwatkar et al., 2026).
  • MIT Technology Review describes layered model defenses as a "Swiss cheese" model in which each layer has holes, and reports that refusal is far from foolproof (MIT Technology Review, 2026).

What does Arthur AI's documentation say the Arthur Engine does?

The page reviewed is Arthur AI's "Self-Host the Arthur Engine" guide (Arthur AI, vendor documentation, accessed October 14, 2026). It describes the product in one line as "a self-hosted evaluation and guardrails engine for LLM applications." The capabilities it lists are real-time guardrails, async LLM-as-a-judge evaluators, continuous production monitoring, RAG evaluation, prompt management, transforms and agent evaluations.

The organizing unit is a task. A task groups the guardrails, evaluators, traces and results for one LLM application. Access runs on API credentials: an admin key and user API keys. The application uses a user API key for its runtime calls to the engine. On guardrails, the page states that they "block or flag bad prompts and responses."

The page reviewed does not state several things a buyer of agent runtime controls will want to know. It does not state whether the engine inspects network traffic, browser sessions, endpoints, data stores, identities or agent configurations. It does not state where the engine sits relative to the model or to the user's screen, beyond the application calling the engine with an API key. It does not state whether the engine detects, classifies, redacts, masks or tokenizes sensitive data, and it does not describe alerting. On agents, it mentions agent evaluations; it does not state that the engine sets policies on agent actions, routes actions for approval or blocks tool calls. On logging, it names traces and results grouped by task and continuous production monitoring; it does not state what a log entry contains or which report formats exist.

Those gaps describe the page, not the product. Arthur AI may document these points elsewhere, and a product named Arthur Shield is outside the page reviewed. A procurement team comparing the two designs should ask Arthur AI for the documentation that covers each point and date what it receives.

What the page does establish is the category. Evaluation and guardrails engines sit in the path of an LLM application's prompts and responses, judge them, and record the results so a team can measure quality and catch bad outputs over time. That is a real and useful job. The OWASP Top 10 for LLM applications treats prompt injection as the first listed risk (OWASP, 2025), and a layer that flags hostile prompts and unacceptable responses addresses part of it. The question for the rest of the comparison is what such a layer does when the "application" is an agent working inside an ERP or a claims system, reading screens full of identifiers and preparing actions with consequences.

Where does each control sit relative to the model and the screen?

Position decides what a control can prevent. A control placed after the model has read the data can judge, flag and record what happened. A control placed before the model reads can decide what the model receives in the first place. AI agent runtime security covers both positions, and they are not interchangeable.

Per its documentation, the Arthur Engine is called by the application through a user API key at runtime, and its guardrails act on prompts and responses (Arthur AI, 2026). The page reviewed does not state its position relative to the model or the screen. In the general guardrail pattern, the check runs on text crossing the application boundary: the prompt on the way in, the response on the way out. Whatever data the application put into the prompt is the data the model reads, and the guardrail's job is to judge it.

RedactSure's published design places the control earlier. The agent works inside a governed environment, a secure virtual machine deployed into the cloud the customer's posture requires, on hardware-encrypted enclaves with keys the customer holds. Every sensitive value chosen by policy, starting with identifiers such as names, SSNs, MRNs, account and card numbers, dates of birth and addresses, is replaced by a consistent token at the render layer before any model reads the screen. The environment hands the model the task's fields, with identifiers as tokens, rather than a picture of the screen. Amounts, dates, codes and the facts the work runs on stay in clear where the policy says so. Real values resolve only at approved destinations at the moment of an approved action.

The difference matters most for screen-operating agents. An agent that reads a claims screen or an accounts payable queue sees everything on that screen. A prompt guardrail can inspect what the application sends, but in the screen case the content arrives as observation, not as a prompt the user typed. Greshake and colleagues showed that instructions hidden in observed content can steer an LLM-integrated application (Greshake et al., 2023), which is why the point of entry is the screen, not the chat box.

How do RedactSure and Arthur AI compare, dimension by dimension?

The table sets the Arthur AI column only from the page reviewed and the RedactSure column only from its published design. Where the Arthur AI page is silent, the cell says so.

Dimension Arthur AI, per its documentation (accessed October 14, 2026) RedactSure, per its published design
Vendor's description "A self-hosted evaluation and guardrails engine for LLM applications" Governed environment where AI co-workers do work across applications with data hidden from the AI
What it inspects or controls Prompts and responses (guardrails); evaluators, traces and results grouped by task; network, browser, endpoint, data stores and identities not stated on the page reviewed What the model receives from each screen, and which actions the agent may take on each screen
Position relative to the model Application calls the engine with a user API key; position relative to the model and screen not stated on the page reviewed Before the model: tokenization at the render layer, then the task's fields go to the model
Sensitive data handling Blocks or flags "bad prompts and responses"; detection, redaction, masking and tokenization not stated on the page reviewed Identifiers chosen by policy become consistent tokens (SSN_001, ACCT_001) before any model reads the screen
Agent actions and approval Agent evaluations mentioned; policies, approvals and tool call blocking not stated on the page reviewed Planner sets policy; a named person confirms it and approves every payment, submission and record change
Record Traces and results by task, continuous production monitoring; log contents not stated on the page reviewed AI Control Record: every action logged, human and computer; all PII as tokens; exported to the customer's SIEM
Deployment and keys Self-hosted Secure VM in the customer's chosen cloud, hardware-encrypted enclaves, customer-held keys
Model coupling Works with LLM applications; model list not stated on the page reviewed Model agnostic; models swap without moving the controls
Integration Application calls the engine through its API No per-application integration; user permissions unchanged

Three rows carry the comparison. The position row shows that the Arthur Engine, as documented, judges what passes between an application and its model, while RedactSure sets what the model can receive. The sensitive data row shows that the page reviewed speaks of blocking or flagging bad prompts and responses, and is silent on transforming sensitive values, while RedactSure's design turns identifiers into tokens before the model sees them. The actions row shows that the page reviewed mentions agent evaluations but does not state an approval step, while RedactSure's design puts a named person on every consequential action.

The table does not rank the products. They address different parts of the runtime problem, and a row that is silent on the Arthur AI side reflects the page reviewed, not a finding that the capability is absent.

What happens to sensitive data and to prompt injection under each design?

Two risks dominate agent runtime: sensitive data reaching the model, and hostile instructions reaching the model. OWASP lists them separately, as sensitive information disclosure (OWASP, 2025) and prompt injection (OWASP, 2025), because a control for one does not settle the other.

On sensitive data, the Arthur AI page reviewed states that guardrails block or flag bad prompts and responses (Arthur AI, 2026). It does not state whether the engine detects personal data, or what it does with it. A buyer whose concern is a model reading Social Security numbers on a benefits screen should ask Arthur AI directly whether the engine transforms those values, and where in the flow.

RedactSure's design treats exposure as the first control. Under Least Exposure, the model receives the task's fields with identifiers as tokens. A model that never receives SSN_001's real value cannot disclose it in a response, cannot store it in a provider's logs and cannot carry it into a later prompt. The work still gets done because amounts, dates and codes stay in clear where the policy allows, and real values resolve only at approved destinations at the moment of an approved action.

On prompt injection, a guardrail that flags hostile prompts is a detection control. Detection has known limits. MIT Technology Review describes stacked model defenses as layers that each have holes (MIT Technology Review, 2026). Wallace and colleagues trained models to prioritize privileged instructions over injected ones, which reduces but does not remove the attack class (Wallace et al., 2024). Bhagwatkar and colleagues found that minimizing what reaches tools, plus sanitizing what comes back, drove attack success on four benchmarks to about 0 percent, and then showed those benchmarks have flawed metrics and weak attacks (Bhagwatkar et al., 2026). The result points two ways: minimization works, and a benchmark score near zero is a starting point for questions.

RedactSure's design does not depend on catching the injection. If an injection succeeds against a RedactSure agent, it collects tokens, and the consequential action it tries to trigger still stops for a named person. The two controls can coexist: a guardrail that flags hostile content reduces how often an agent goes off course, and a design that limits what the agent can read and what it can do without approval limits the cost when it does.

The Microsoft AI Red Team's taxonomy of agentic failure modes separates security failures, such as injection and data exfiltration, from safety failures, such as harmful outputs (Microsoft, 2025). An evaluation engine is built around measuring outputs. An exposure and approval environment is built around limiting what an agent can reach and do. A program with agents on regulated records needs both kinds of answer.

Who approves the agent's consequential actions, and what lands in the record?

An agent that pays an invoice, submits a claim or changes a student record has done something a reviewer will later ask about: who approved it, and what proves it.

The Arthur AI page reviewed mentions agent evaluations (Arthur AI, 2026). It does not state that the engine sets policies on agent actions, sends actions to a person for approval or blocks tool calls. Evaluation, listed beside LLM-as-a-judge evaluators and production monitoring, measures how an application performs. Holding a specific payment until a named person signs it is a different function.

RedactSure's design applies 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. The Planner sets which values are tokenized and what the agent may do on each screen; the person confirms that policy before the run, and every payment, submission and record change waits for approval. The AI never pays, settles, submits or decides on its own. Permissions do not change; what changes is what the AI can see.

A model reviewing its own work is a weak final check. The case against letting an AI vendor's own model act as the safety reviewer extends to any LLM-as-a-judge used as the last gate on a payment. The NIST AI Risk Management Framework places accountability under its Govern function, which assigns roles and responsibilities to people (NIST, 2023).

On the record, the Arthur AI page names traces and results grouped by task and does not state what a log entry contains. RedactSure's design writes every screen the agent saw (as tokens), every action and every approval with a name into the AI Control Record: every action logged, human and computer; all PII as tokens. It exports to the customer's SIEM, and because identifiers are tokens, the audit trail is not a second copy of the sensitive data. A buyer should request a sample record from each vendor and check who approved each consequential action and what the agent saw.

Where does RedactSure sit?

RedactSure sits before the model and before the action. Inside a governed environment deployed in the cloud the customer chooses, with customer-held keys, identifiers chosen by policy become consistent tokens at the render layer before any model reads the screen, and the model receives the task's fields. A named person confirms the policy and approves every consequential action, and the AI Control Record exports to the customer's SIEM. A successful injection collects tokens, and the action it aims at still stops for a named person. The design is model agnostic and needs no per-application integration; deployments are in pilot. An evaluation and guardrails engine can run alongside it on the application's prompts and responses.

Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on one vendor document, Arthur AI's "Self-Host the Arthur Engine" guide, read on October 14, 2026, and on published sources read as of October 13, 2026: the OWASP Top 10 for LLM Applications 2025 (standards guidance), the NIST AI Risk Management Framework (official guidance), peer-reviewed research and preprints from Greshake and colleagues, Wallace and colleagues, and Bhagwatkar and colleagues, a Microsoft AI Red Team whitepaper (vendor research), and MIT Technology Review (press). RedactSure statements reflect its current published design, not a measured deployment.

No product was tested hands on, and no benchmark was run against either design. Arthur AI may document capabilities on pages not reviewed here, including Arthur Shield, and wherever the table says a point is not stated, that describes the page reviewed only. Vendor features change; the page carries its date, and readers should confirm each row against current documentation before a decision. No specific organization's deployment is described, named or implied.

Whether a given control set satisfies a regulation, a contract or an internal policy is a determination for the organization's counsel, its assessors and its security and compliance officers. The comparison supplies questions to ask and a structure for recording the answers, not that determination, and it does not replace a vendor security review.

What the record shows

Arthur AI's documentation describes an engine that evaluates and guards an LLM application's prompts and responses and monitors it in production. An exposure and approval environment decides what an agent's model receives from each screen and holds each consequential action for a named person. Relying on a guardrail alone for an agent on regulated records leaves the model reading every identifier on the screen and leaves no stated approval step for actions. The test: ask each vendor to show, in its own record, what the model saw and who approved the last payment the agent made.

Frequently asked questions

Is Arthur AI a competitor to RedactSure?

They overlap on the phrase "runtime controls" and differ on function. Arthur AI documents an evaluation and guardrails engine for LLM applications. RedactSure documents a governed environment that limits what an agent's model sees and requires a named person's approval for consequential actions. Many programs will want both kinds of control.

Does the Arthur Engine redact or tokenize sensitive data?

The page reviewed, accessed October 14, 2026, does not state that it detects, redacts, masks or tokenizes sensitive data. It states that guardrails block or flag bad prompts and responses. Ask Arthur AI for current documentation on sensitive data handling before relying on it for that purpose.

Can a guardrail stop prompt injection on its own?

A guardrail can catch many injections, and research shows detection has gaps. MIT Technology Review describes layered model defenses as each having holes. A design that limits what the model reads and requires approval for consequential actions reduces what a successful injection can reach or do.

Does RedactSure replace LLM evaluation and monitoring?

No. RedactSure governs exposure and action: what the model receives and who approves what the agent does. It does not describe itself as an evaluation engine for output quality, drift or RAG accuracy. An organization measuring model quality would keep a tool built for that job.

Who approves an agent's actions under each design?

Under RedactSure's design, a named person confirms the policy before the run and approves every payment, submission and record change during it. The Arthur AI page reviewed mentions agent evaluations and does not state an approval step for agent actions.

What should a buyer ask both vendors for?

A sample record from a real run. Check whether it names who approved each consequential action, shows what the agent saw, and keeps sensitive values out of the log. Also ask where the control sits relative to the model, and date every answer you receive.

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.