Skip to content
redactsure
Book a demo

Explore.

Comparison · By Chris Sowa · Published
Last updated

What Is the Difference Between RedactSure and Portkey (Prisma AIRS AI Gateway) for AI Agent Data Protection?

Portkey, now Palo Alto Networks' Prisma AIRS AI Gateway, redacts PII irreversibly in requests routed through it, while RedactSure tokenizes the rendered screen an agent reads and resolves real values only after a named person approves. Ask each vendor which control decides what the model sees on the first screen, and how the real value reaches the final field.

Document fields cross a narrow boundary beside a separate process that substitutes fields and reconnects them to records.

Portkey, now Palo Alto Networks' Prisma AIRS AI Gateway, redacts PII irreversibly in requests routed through it, while RedactSure tokenizes the rendered screen an agent reads and resolves real values only after a named person approves. Ask each vendor which control decides what the model sees on the first screen, and how the real value reaches the final field. A gateway sees the traffic an application sends; it does not see the page an agent reads. The gateway belongs to the family RedactSure's comparison with Prisma AIRS for AI agent runtime security examines. That page covers runtime threat inspection of AI applications and models; this one covers the gateway and its redaction. The difference shows up in two places. The first is the point of control: a gateway acts only on what is routed through it, and an agent reading a claims screen does not route that page through a gateway as a request. The second is what happens to the value: an irreversible placeholder protects the model but cannot complete a task that needs the real value at the end, which is why render-layer tokenization keeps a governed route back. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • Palo Alto Networks announced general availability of Prisma AIRS AI Gateway on July 16, 2026, describing it as "a unified LLM, MCP, and A2A Gateway with a single enforcement point" for traffic routed through it (Palo Alto Networks, 2026).
  • Portkey's documentation says the gateway "automatically detects and redacts sensitive information from requests before they reach the LLM," using numbered placeholders such as {{EMAIL_ADDRESS_1}}, and states: "Redaction is irreversible by design" (Portkey, 2026; Portkey, 2026).
  • Guardrails check only "the last message in the request body," and the default asynchronous mode logs results rather than blocking the request (Portkey, 2026).
  • The MCP Gateway lists "approval workflows per server" without further detail; the pages reviewed describe no per-action human approval and do not address agents that read rendered screens (Portkey, 2026).
  • OWASP lists sensitive information disclosure as a top risk for LLM applications, covering personal data and confidential business data that reach or leave a model (OWASP, 2025).
  • A 2026 study found that a model-agnostic firewall which strips unneeded data before tool calls, paired with one that cleans tool outputs, brought attack success near zero on four agent benchmarks (Bhagwatkar et al., 2026).

What does Portkey's documentation say the gateway covers?

Portkey describes an AI Gateway platform that bundles routing, observability, guardrails, governance and prompt management for API requests routed through it, and its site now carries the banner "Portkey is now PRISMA AIRS AI Gateway" (Portkey, 2026; vendor documentation, accessed October 16, 2026). On completing the acquisition, Palo Alto Networks called the gateway "a mission-critical control plane for the enterprise," a plane that sees only the model traffic a team sends through it (Palo Alto Networks, 2026). The general availability post of July 16, 2026 focuses on "coding assistants, enterprise agents, and copilots" (Palo Alto Networks, 2026).

The gateway is a proxy with three faces. Applications and agent frameworks route model calls through it, MCP clients route tool calls through the MCP Gateway, and A2A agent servers route through the Agent Gateway (Portkey, 2026). Portkey lists integrations with 15 agent frameworks, including OpenAI Agents, LangChain, LangGraph, CrewAI and AWS AgentCore, each a change to code a team owns (Portkey, 2026). The MCP Gateway "acts as a proxy between MCP Clients and MCP servers, handling authentication, access control, and logging," with the ability to "enable or disable specific tools per user," on a path that carries tool calls rather than rendered pages (Portkey, 2026). Its launch post says centralized guardrails enforce PII redaction and content policies across entities, for requests that pass through the gateway (Portkey, 2026).

Each of those controls acts on traffic sent through the gateway. That is the boundary RedactSure's comparison of RedactSure and an AI gateway draws in general terms: a proxy governs the flow that runs through it.

The pages reviewed do not state several things a buyer evaluating browser-based agents will ask about. They do not describe controls for agents that read rendered screens or work applications outside the API path, a way for a placeholder to resolve back to its value, or how "approval workflows per server" work. Other pages may carry that detail.

What happens to a sensitive value in each design?

Take a single record: a claims payment screen showing a claimant's name, date of birth, policy number, the payee's bank account number and an approved amount. An agent has been asked to issue the approved payment.

In Portkey's design, protection begins when the agent's framework sends a request through the gateway, where PII redaction is a configured guardrail. Detection comes from the configured provider, which may be Portkey's own PII detector, Patronus AI, Pangea, AWS Bedrock Guardrails or Promptfoo, or from custom regular expressions (Portkey, 2026). Built-in entity types include phone numbers, email addresses, locations, IP addresses, Social Security numbers, names and card numbers (Portkey, 2026). The built-in list does not name bank account numbers, and built-in patterns cannot be customized, so that field would depend on a provider's detector or a custom expression (Portkey, 2026). The check applies to "the last message in the request body" (Portkey, 2026).

The documentation is direct about what follows: "Redaction is irreversible by design" (Portkey, 2026). For a chat request whose answer never needs the original, that fits. For this task it does not. The payment field needs the payee's real account number, and an irreversible placeholder either leaves the payment unfinished or forces the real value back into the model's path. See runtime tokenization versus redaction.

In RedactSure's design, the agent works the claims application inside a governed environment. Before any model reads the screen, the name, date of birth, policy number and account number become consistent tokens such as SSN_001 and ACCT_001. The approved amount stays in clear, and the same account is the same token on every screen. When the agent reaches the payment field, the real account number resolves only at that approved destination, at the moment a named person approves the payment.

Instructions planted in content an LLM application reads can redirect it (Greshake et al., 2023), and an agent holding ACCT_001 can give an injected instruction only a token.

How do the two compare side by side?

The table records what each side's documentation states. For Portkey, that is the documentation and announcements listed in the sources, accessed October 16, 2026, including the general availability post of July 16, 2026 (Palo Alto Networks, 2026). For RedactSure, it is the current published design.

Dimension Portkey (Prisma AIRS AI Gateway), per its documentation RedactSure, per its published design
What it inspects or controls Model, MCP and A2A traffic routed through the gateway; tools enabled per user The screen an agent reads in a governed environment, and its actions there
Position relative to the model and the screen Proxy in the API path; position relative to the screen not stated in the pages reviewed Between the rendered screen and the model, before any model reads it
What it can see Requests and responses routed through it Every screen the agent reads in any application it works
Treatment of a sensitive value Numbered placeholder such as {{EMAIL_ADDRESS_1}}, or fixed text from a custom pattern Consistent token per entity, chosen by the Planner's policy
Route back to the real value "Redaction is irreversible by design" Real values resolve only at approved destinations at the moment of an approved action
Scope of a check "The last message in the request body"; default mode logs rather than blocks Every rendered screen in the run
Integration Route traffic through the gateway; guardrails referenced in a per-request configuration No per-application integration; permissions unchanged
Agent actions and approval Allow or deny by guardrail; "approval workflows per server" listed without detail A named person confirms policy and approves every payment, submission and record change
Record Tool calls logged with user, parameters and response; log handling of originals "varies by guardrail provider" Every action logged, human and computer; all PII as tokens; the AI Control Record exports to the customer's SIEM

Several Portkey cells say "not stated" or "without detail." Those cells describe the pages, not the product's full capability, and a buyer should confirm each one with Palo Alto Networks. The RedactSure column describes a design in pilot.

What does a gateway see when an agent works through the browser?

Portkey's integration is light for code a team writes: "Integrate Portkey in just 3 lines of code," or two for agents, by changing the base URL and adding headers (Portkey, 2026). Guardrails are created in the gateway's interface and referenced in a configuration attached to each request. For software the organization builds, that puts one enforcement point on model traffic.

That cannot be done for applications the organization did not build. A carrier's claims platform will not route its pages through a customer's gateway, and an agent operating it through a browser reads the page the application renders. That page is not a request body. What the model receives is assembled from the screen, and the decision about which values it needs is made, or not made, before any request reaches a proxy. The general case is set out in screen-level tokenization versus API-level filtering.

RedactSure's integration point is the environment the agent works in. A new application costs a field-by-field tokenization policy confirmed by a named person, not a change to someone else's code.

Microsoft's AI Red Team taxonomy of agent failure modes includes failures that occur during execution even when configuration was sound (Microsoft, 2025). A browser agent's execution happens on the screen. The NIST AI Risk Management Framework separates mapping a system's context from managing its risks in operation (NIST, 2023). Mapping a browser-based workflow shows two boundaries: the model call, where a gateway works, and the rendered page, where exposure begins.

How do approval and the record differ?

Portkey's guardrails decide whether a request routed through the gateway proceeds; they do not put a person in front of an action. With "Deny" enabled, a failed check returns status 446 and blocks the request; the default passes it through with a 246, and output guardrails on streaming responses are "informational only" (Portkey, 2026). The MCP Gateway names approval workflows per server, and the pages reviewed do not describe how they work or who approves (Portkey, 2026). Every tool call through the MCP Gateway is "logged with user, parameters, and response" (Portkey, 2026).

In RedactSure's design, a person makes the action decision. Under 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, and the named person confirms that policy before the run. The agent never pays, submits or changes a record on its own authority.

Model-internal defenses have gaps. MIT Technology Review reported in October 2026 that model refusal is treated as a primary safety mechanism and is far from foolproof, with vendors stacking layered defenses whose individual holes they hope will not line up (MIT Technology Review, 2026). OWASP describes prompt injection as a risk that can cause a model to take unintended actions (OWASP, 2025). If an injection succeeds against a RedactSure agent, it collects tokens, and the payment still stops for a named person.

Portkey's documentation says the handling of original values in logs "varies by guardrail provider" (Portkey, 2026), so a buyer should ask which behavior applies. In RedactSure's design, the AI Control Record captures every screen the agent saw as tokens, every action and every approval with a name, and exports to the customer's own SIEM. The two gaps this closes are described in The Two Gaps AI Agents Opened in Your Security Stack.

Where does RedactSure sit?

For agents that work operational applications through the browser, RedactSure sits at the screen, between the rendered application and the model. Inside a governed environment deployed into the customer's cloud, on hardware-encrypted enclaves with keys the customer holds, identifiers chosen by policy are replaced with consistent tokens before any model reads the screen. Real values resolve only at approved destinations at the moment of an approved action, and a named person approves every payment, submission and record change. The environment is model agnostic, needs no per-application integration and leaves user permissions as they are. Deployments are in pilot. A gateway such as Portkey's complements it at the model-traffic layer, governing the requests that applications and agent frameworks a team builds send through it. The gateway governs requests; RedactSure governs the screens an agent reads and the actions it takes.

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

Methodology and limitations

This page rests on Portkey's homepage, documentation and MCP Gateway launch post, and Palo Alto Networks' acquisition release and general availability post, all accessed October 16, 2026 (vendor documentation); OWASP's Top 10 for LLM Applications 2025 and the NIST AI Risk Management Framework (standards); preprint research on prompt injection and agent firewalls; analysis from Microsoft's AI Red Team and MIT Technology Review; and RedactSure's published design.

No hands-on testing of Portkey or any other named product was performed. Palo Alto Networks' completion release carries two dates in its page metadata, so this page cites it without asserting a closing date, and many Portkey pages are undated. Where the pages reviewed do not state a capability, the table says so; other documentation may describe it. Prisma AIRS runtime components were outside scope. Vendor features change, and the page carries its date. RedactSure statements describe the current design, with deployments in pilot. No specific organization is described.

Whether either product, or both together, meets an organization's obligations is a determination for its counsel, its assessors, and its own security and compliance officers. A buyer should confirm each "not stated" cell with Palo Alto Networks and request a demonstration of RedactSure's tokenized screen on the buyer's own task before relying on any row of the comparison.

What the record shows

Portkey's documentation describes a gateway for traffic a team controls, with redaction that is irreversible and checks that see the last message in a request. Browser-based agents need two things the pages reviewed do not describe: protection of the page they read, and a governed way to complete the task with the real value after a person approves. That is the reason to choose RedactSure for browser-based agent work, with the gateway kept on model traffic. The test is to name one agent and one task and ask each vendor to show what the model received from the first screen and what put the real value into the final field.

Frequently asked questions

Is Portkey part of Palo Alto Networks now?

Yes. Palo Alto Networks acquired Portkey, and the product is now Prisma AIRS AI Gateway, generally available since July 16, 2026. Portkey's site carries the banner "Portkey is now PRISMA AIRS AI Gateway." This page cites the completion release without asserting a closing date, because the release carries two dates.

Does Portkey tokenize data before the model sees it?

Portkey redacts PII in requests routed through the gateway, irreversibly, replacing values with numbered placeholders such as {{EMAIL_ADDRESS_1}} or fixed text from a custom pattern. Its documentation says the redaction is irreversible by design. RedactSure's tokens are consistent per entity across every screen of a run and resolve to real values only at approved destinations when a named person approves.

Can an AI gateway protect what an agent reads on a web page?

Not on the pages reviewed. A gateway acts on requests and responses routed through it, and its guardrails check the last message in the request body. A page an agent reads in a vendor's application is not routed through a model gateway as a request, so what the model sees there is decided elsewhere.

Does Portkey require human approval for agent actions?

The MCP Gateway lists approval workflows per server without describing how they work. At the request level, guardrails allow or deny, and the default mode logs rather than blocks. RedactSure requires a named person to approve every payment, submission and record change, recorded in the AI Control Record.

How does this page differ from the Prisma AIRS comparison?

The Prisma AIRS comparison covers runtime threat inspection of AI applications and models. This page covers the AI gateway that came from Portkey: its position in the API path and its irreversible PII redaction. Both reach the same point: controls on model traffic do not decide what a model reads from a rendered screen.

Can an organization use an AI gateway and RedactSure together?

Yes. The gateway governs model, MCP and A2A traffic for software a team routes through it. RedactSure governs agents that work applications through the browser, tokenizing each screen and holding each consequential action for a named person. They protect different paths, and each covers ground the other does not.

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.