Developing Secure AI Agents on Guidewire
This guidance is for developers, teams, and partners building AI agents on the Guidewire platform. It covers the security decisions that matter most when you take an agent to production, and it draws a clear line between what the platform secures for you and what you own.
AI agents change the threat model. A traditional web application has a fixed set of inputs and outputs you can reason about at build time. An agent doesn’t. It reads documents, calls tools, pulls data from several systems, and writes responses that go straight to your users. That flexibility is the point of an agent. It’s also what makes securing one harder.
Most of the risks aren’t new. Prompt injection, leaked PII, a wrong number in a summary, a tool with more access than it should have. They tend to show up the same way and respond to the same fixes. The hard part is knowing which controls belong to the platform and which ones you wire in yourself.
Why This Guidance
Guidewire builds the agentic platform with security in the foundation. That includes tenant isolation, identity propagation, a server-side instruction layer, and PII redaction in operational traces. Those controls give you a secure base, but they don’t finish the job. The choices that decide whether your specific agent is safe, what input it accepts, what data it sends to the model, and what its tools can do are yours. This guidance helps you make them well.
How to Use This Guidance
Read this overview first, then the two sections that follow:
- Securing Agents on the Merlin Platform covers what the platform secures and where your responsibility begins. Start here if you’re assessing the platform
- Securing a Claim Summarization Agent is a worked, code-level example of the highest-risk pattern: an agent that reads untrusted documents. Start here if you’re building
The Shared Responsibility Model
Think of it as a secure engine and a safe driver. Guidewire provides the engine and handles the infrastructure-level controls that run whether you think about them or not. You are the driver. How you configure the agent's logic, what you send to the model, and what its tools are allowed to do are your decisions. A strong engine doesn’t stop a driver from going somewhere they shouldn’t
The purpose of this model is to make ownership clear, so important work doesn’t fall into the gap between what the platform handles and what teams assume the platform handles. The matrix below defines that boundary.
Shared Responsibility Matrix
For each control, the table states what the platform provides, whether it’s active by default, and what you do to be production-ready. "Always on" means the control runs with no configuration. "Configurable" means the platform provides the capability through a per-tenant profile and you turn it on and tune it. "Your responsibility" means you build it at the application layer.
| Platform Capability | Default Status | Your Responsibility |
|---|---|---|
| Instruction Isolation. A server-side security prompt that makes the model treat anything it reads or receives as content to process, never as instructions to follow | Always on | Write application prompts that work with the boundary rather than trying to override it. |
| Model Safety Alignment. Provider-level safety behavior in the underlying model | Always on | Treat it as a backstop, instead of your only line of defense. |
| Gateway Prompt-Attack Monitoring. The gateway watches inbound prompts for known instruction-hijack patterns | Always on (monitoring) | This is a detection signal to review.. Review the signals for your agent, and add application-layer checks for the input you accept. Your own filterPrompt() and structural delimiters are the active defense. |
Tenant and Infrastructure Isolation. Per-tenant data separation, per-user scoping, and encryption at rest and in transit. The agent acts as the calling user, with identity carried in the GW-User-Context header | Always on | Use the propagated identity for access decisions in custom tools and external integrations (e.g., outbound API calls or third-party databases). Don't build custom paths that bypass user entitlements or return more than the calling user may see. |
| PII Redaction in Traces. Operational traces are scrubbed of sensitive entities (18 types) before they reach telemetry tooling | Always on | Audit any custom trace fields you add so they don’t slip data past the standard redaction. |
| PII Entity Masking. Regex matchers that redact sensitive patterns from input to and output from the model | Default-on for output scopes; input opt-in by design | Turn it on and extend the matchers for your data through GwAgents.configure({pii}). Decide your input-PII strategy (see the Claim Summarization section). |
| Tool Execution Boundaries. Tools are denied by default; arguments are validated against your schema before a call runs | Always on | Define a restrictive typed schema for every tool and authorize each operation. No wildcard handlers. |
| Tool Response Size Limits. Data returned from a tool into the model context is capped to bound exfiltration and context exhaustion | Always on (about 50,000 characters) | Design downstream payloads to handle truncation rather than assuming the full result reaches the model. |
| Content Safety and Word Filters. Provider content-safety categories and custom word or phrase filters | Configurable (per-tenant profile) | Turn these on and tune them for your line of business. Insurance narratives include sensitive incident detail, so generic settings need adjusting. |
| Fail-Closed Behavior. On a guardrail outage, the platform fails closed rather than passing traffic through | Always on | Design your agent to return a safe error, rather than a partial answer, when a call fails. |
How The Platform Is Assured
The gateway, the vector store, and the container images go through a STRIDE-LM threat model and a secure-code review by the Guidewire Product Security Assurance team. The runtime is tested under live adversarial conditions through an independent external penetration-testing program. Security review is part of the release process.
Additional Resources
Standards and References
- OWASP Top 10 for Large Language Model Applications
- OWASP LLM Prompt Injection Prevention Cheat Sheet
- OWASP GenAI Security Project
- OWASP - Open Web Application Security Project
- NIST AI Risk Management Framework
- MITRE ATLAS, the adversarial-threat knowledge base for AI systems
Guidewire Documentation
Was this page helpful?