Does WRITER use customer prompts to train its models?

WRITER states that customer data and user inputs are excluded from creating, modifying, or training its models. Outputs are excluded as well. Security and procurement teams should preserve the current trust-page statement with the applicable contract and workspace settings. They should also record the review date. The same evidence packet should record the automated deletion schedule configured for the organization because model-training use and operational retention answer different questions.

What should a WRITER Agent permission test include?

Use named test identities with different access to one synthetic knowledge source or Connector. Run the same task under each account and retain the WRITER Agent configuration with the permission assignment. Preserve the approval event and activity trace, along with the connected-system result. The test demonstrates delegated authority at the point where the platform accepts or denies access instead of inferring authority from successful login.

Can an external gateway inspect every WRITER Agent action?

Coverage is limited to model-bound HTTP traffic explicitly routed through the gateway. WRITER Connector and tool calls to Salesforce and SharePoint remain under WRITER's governed execution layer and the receiving application's controls. The same applies to calls to another application. Direct hosted-interface traffic also stays outside the gateway when WRITER provides no supported external route for that inference hop.

Which identity should reach the model policy point?

The calling application should supply the originating human or agent identity with the routed HTTP request. Useful context includes the role and tenant. It should also include the purpose and prompt classification, along with the destination and requested operation. A single integration key collapses every employee into one service principal. Policy can evaluate that service identity, but it cannot reconstruct an upstream person whose identity was omitted.

WRITER Security: Map Platform Controls to the Model Route

A WRITER Agent request begins inside an enterprise AI platform that can identify the user and apply permissions. It can consult approved knowledge and invoke configured tools. It also records activity. A separate model API call may follow a different route under a shared service credential. Those paths need separate control maps. I want to trace writer security through the platform first, then isolate the exact HTTP boundary where an independent policy decision can apply before an LLM receives a routed request.

TL;DR

WRITER provides native identity validation and permissions. It also provides approval flows, activity traces, decision logs, and centrally configured agent guardrails.
Its data controls cover model training use, retention settings, encryption, and customer isolation within the enterprise AI platform.
Connector and tool actions remain governed by WRITER and the connected application. Separately routed LLM requests need their own route inventory.
DeepInspect applies only to authenticated HTTP model traffic explicitly routed through its proxy with usable identity context.

Native governance starts with identity and permissions

WRITER describes an integrated control path. Its trust and governance documentation says the platform validates identity and checks granular permissions. It supports approval flows and records activity traces with source citations. It also maintains decision logs. The same page describes a governed execution layer for agent requests to connected systems. That layer checks the requesting identity and its permissions before the action proceeds.

A security review should exercise that path with named test users. Give one account access to a synthetic finance source and withhold it from a second account. Run the same WRITER Agent task under both identities, then preserve the permission configuration and resulting activity records. The useful evidence is a pair of screenshots. One contains the approved source card, while the other shows the denied path. A generic SSO screenshot leaves agent authority unresolved.

The post-authentication gap still matters. Authentication establishes the principal. Each delegated task also needs a decision about the sources and tools that principal may use. The decision must also cover connected systems and the model route for this request.

Agent configuration defines delegated authority

The current WRITER Agent product page describes permissions over Connectors and tools. It also covers permissions for knowledge sources, along with centrally configured guardrails and system-wide analytics that include audit logs and usage trends. WRITER currently uses Playbooks, Skills, Connectors, Voice and style guide, and AI Studio as product terms. Palmyra names its model family. Older AI HQ language should stay out of a current architecture diagram.

Map each production agent to an owner and its approved knowledge sources. Record its enabled Skills and permitted Connectors, along with any approval step before an external action. Then run a controlled task that crosses one permission boundary. Capture the agent configuration version and the human approval record alongside the execution result.

I would reject an agent review built around a polished catalog of use cases. Security lives in the denied test. One red permission icon beside a blocked connector tells the reviewer which boundary actually executed; a page of approved examples only shows the happy path.

Data handling needs tenant-specific verification

WRITER states that customer data and user inputs are excluded from creating, modifying, or training its models. Outputs are excluded as well. Its trust page also says administrators can configure organization-wide data controls, including an automated deletion schedule. WRITER characterizes its retention posture as a zero data retention approach while qualifying that data is stored for as long as needed to provide the platform. Preserve that qualification in procurement records and architecture notes.

The same source describes encryption in transit and at rest. Customer data is provisioned in an isolated production project. The source also describes support for major SSO providers and MFA, annual SOC 2 Type II evaluations, and certifications under ISO/IEC 27001 and 27701, plus ISO/IEC 42001. These vendor controls support due diligence. Tenant evidence should add the configured identity provider and deletion schedule. It should also identify the enabled model path and approved knowledge sources.

Create one evidence packet for the deployed configuration rather than relying on a trust-page printout. The packet should tie WRITER's published commitments to the settings and routes used by the named production workspace.

Connected-system actions sit outside the model gateway

A WRITER Agent can use Connectors and tools to work with enterprise systems. WRITER's governed execution layer is the native control for those requests. The receiving application also applies its own authorization to records and actions. A Salesforce update or SharePoint retrieval is an application API event. A ticket change is too. It should never be relabeled as LLM inference merely because an agent initiated it.

This distinction determines control ownership. WRITER administrators own agent configuration and platform permissions. Application teams own business authorization in connected systems. IAM owns SSO and MFA. It also owns provisioning and account lifecycle. The AI gateway architecture applies only to a model-bound HTTP request placed on that route.

Draw separate arrows for knowledge retrieval and tool execution. Add another arrow for inference. Label the credential and policy owner on each arrow. A single arrow called AI hides the exact handoff an engineer needs to inspect.

External model routes require a separate decision point

An enterprise may use WRITER for governed agent work and still operate direct LLM APIs in internal services, developer tools, or other SaaS products. Inventory those routes by caller and endpoint. Record the credential and model, then add the data class and business purpose. Each customer-controlled HTTP path can then receive an explicit policy before forwarding.

AI policy enforcement at the HTTP layer evaluates the identity and context supplied by the calling application. The decision can bind a role and prompt classification to one request. It can also bind the destination model and requested operation, along with the versioned policy. A shared service credential identifies only that service unless the application forwards the originating user or agent identity.

Direct use of WRITER's hosted interface and WRITER-managed internal inference remain outside an external gateway when no supported route crosses it. The same boundary excludes local execution and connector traffic to business applications. A route diagram and captured HTTP request should prove coverage before the security review credits an independent enforcement point.

DeepInspect

This is the gap DeepInspect closes for customer-controlled model routes. DeepInspect is a stateless proxy for HTTP AI traffic between authenticated users or agents and LLM endpoints. When an application explicitly routes that traffic through the proxy and supplies identity context, DeepInspect evaluates the request against identity-bound, versioned policy before forwarding it.

WRITER continues to govern its hosted platform and WRITER Agent permissions. It also governs approval flows and data settings. Connectors and connected-system execution remain under WRITER's control. DeepInspect adds an independent allow or deny decision. It can also redact the request and create a signed, tamper-evident record for each routed LLM request. Hosted WRITER inference and application API actions stay outside that enforcement boundary. Book a technical deep dive at deepinspect.ai.