Securing Agents on the Merlin Platform
This section walks through each platform control, including what it does, and where the line to your responsibility sits. Everything here describes capabilities that are live today.
Instruction Isolation
Every agent invocation runs behind a server-side instruction layer. Its most important job is to make sure anything the model reads, retrieves, or receives as content to process, never as instructions to follow. That helps prevent a hostile document or a crafted message from redefining the agent's behavior or coaxing out its configuration.
Because this layer is applied server-side, you can’t weaken it by accident, and an attacker can’t turn it off through the prompt. Your job is to write application prompts that work with it. Avoid instructions that assume the model will obey content it was handed or that attempt to re-grant the model authority the layer holds back. The instructions you author are forwarded to the model as-is. The platform doesn’t validate them against the isolation layer, so review your instruction text during your security process.
Tenant and Infrastructure Isolation
Customer data is separated per tenant at the infrastructure layer, and the data is encrypted at rest and in transit. An agent doesn’t run with platform-wide privilege. Instead, it acts as the user who invoked it, with that identity carried through the request in the GW-User-Context header. The platform enforces per-user scoping on the primary data paths. (Some multi-user retrieval paths use shared collections by design, protected by non-guessable identifiers and tenant isolation.)
Your responsibility is to rely on that propagated identity for access decisions, and to avoid building any path, a tool, an integration, or a cache that reaches across tenants or returns more than the calling user's own entitlements.
PII Redaction in Traces
Operational traces are scrubbed of sensitive entities, 18 types in total, before they leave your environment for telemetry tooling. This protects the monitoring path, the traces and metrics your teams use to watch the agent, so sensitive values don’t pile up in downstream dashboards.
The standard trace body is covered, but custom fields in span tags, error metadata, or evaluation outputs follow a different path, so audit those separately. If you add custom fields to traces, check them to make sure your own parameters don’t carry sensitive data past the standard redaction.
PII Entity Masking
The platform provides regex matchers that redact sensitive patterns from what goes into the model and what comes back out. You turn this on and tune it through a per-tenant profile, using GwAgents.configure({pii}). Output-scope masking is enabled by default for the OOTB matchers. Input-scope masking is opt-in by design. The built-in matchers cover structured patterns (SSN, credit card, tax ID, phone, email). Unstructured PII (names, addresses, medical narratives) isn’t detected by regex. Use the data-minimization pattern for that.
Two things are yours. First, enable and extend the matchers for your domain. When an insurance identifier looks like a built-in entity and gets masked by mistake (a claim number read as an SSN, for example), add a custom matcher or override rather than turning masking off. Second, decide your input-PII strategy, which the Claim Summarization section covers in detail.
Tool Execution Boundaries
Tools are denied by default. A tool isn’t callable until you authorize it, and its arguments are checked against the schema you declare before the call runs. Wildcard handlers aren’t allowed. A schema that accepts arbitrary input provides no meaningful validation, so define the narrowest type for each parameter.
Your responsibility is to define a restrictive, typed schema for every tool and to authorize each operation. A tool without a schema gives up this protection. Treat tool responses, including those from external MCP servers, as untrusted content. Wrap them in structural delimiters before they enter the model context, the same way you wrap uploaded documents. The Claim Summarization section covers per-call authorization in depth.
Tool Response Size Limits
Data returned from a tool back into the model context is capped, with a working figure of about 50,000 characters [verify], to bound two risks at once. First, a compromised or chatty tool moving large volumes of data through the model. Second, the context window filling up and degrading the agent.
Design downstream payloads to handle that limit cleanly, rather than assuming a tool's full result reaches the model intact.
Content Safety and Word Filters
Content-safety categories and custom word or phrase filters are available through a per-tenant profile. You turn them on and tune them for your line of business. This matters in insurance because claims work involves accident, injury, and liability detail that generic content settings tend to over-block, so the right configuration is specific to your domain. Insurance-specific profiles are what make these usable. Generic category settings over-trigger on legitimate claims content.
Decide which categories and terms your business line needs to flag or block, then set them at the tenant level where you can tune them without breaking legitimate claims processing.
Fail-Closed Behavior
If a guardrail component is unavailable, the platform fails closed rather than letting traffic through unchecked. Build your agent to expect that. Return a safe error to the user instead of a partial or unguarded response.
Additional Resources
Was this page helpful?