A deliberate control point for AI tool access.
Ovatio Comply sits in the path of supported AI tool calls that you choose to route through it. It helps regulated teams apply policy consistently before a request reaches a connected system, protect configured confidential fields in the response, and retain the decision for internal review.
One request. Clear controls.
Identify the caller
- Caller (Consumer)
- Client Service Assistant
- Assigned role
- Client Service
Comply uses the configured caller's role to evaluate access.
Apply the route's policy
- Integration
- Client Records API
- Endpoint
GET /clients/{client_id}
Allow this lookup. Apply the configured response controls before returning data.
Limit what comes back
Post-Response Constraints
account_numberRedact internal_noteFrom the business system
- Client name
- Example Client
- Account number
- 12345678
- Internal note
- Exception under review
Returned to the assistant
- Client name
- Example Client
- Account number
- ****5678 Masked
- Internal note
- Removed from response
From the system Returned to the assistant
- Client name
- Example Client Unchanged
- Account number
- 12345678 → ****5678 Masked
- Internal note
- Exception under review → Removed
The account number keeps its last four characters. The internal note field is removed entirely.
Inspect the decision
Redacted: internal_note
Review the request journey, response changes, and associated decision records.
One governed path for selected connections
Teams deliberately route supported REST, MCP, wrapped MCP, and limited GraphQL traffic through Comply. That creates a clear boundary where the organization can apply its own rules. Connections that do not traverse Comply remain outside that boundary.
Check the request before it reaches the system
For configured routes, Comply identifies the Consumer, loads server-side roles, and evaluates endpoint, request, field, and value rules. It can allow or deny the request, or hold eligible actions for a human decision. These controls govern the routed request; they do not replace the connected system's own authorization model.
Control selected data in the response
Comply can inspect nested response objects and arrays, then redact or mask configured confidential fields and values before the result returns. This is field and value control. It is not general row-level authorization, so the exact response policy should be designed around each supported integration.
Make integration change visible
Comply can inventory configured capabilities and surface schema changes for review. Breaking changes can suspend affected policy. Route behavior and policy coverage still need to be validated for the release configuration before a team relies on them.
Keep people responsible for policy
Comply can generate structured policy suggestions to reduce the work of drafting controls. Those suggestions remain advisory until a person reviews and activates them. The system records human approvals and denials so accountable owners can see how consequential decisions were made.
Evaluate it in a controlled, private scope
Comply is currently positioned as a controlled, single-tenant Azure Managed Application evaluation. The deployment can be placed in a customer's Azure subscription with configured publisher and just-in-time support paths. Production criteria, support access, integrations, and operating responsibilities are defined for the customer scope.
Retain decision records for review
Comply records hash-chained audit events and can verify the active chain. Bounded exports include hashes and payload digests. A portable proof of the entire chain requires a separately defined trusted checkpoint or anchor, so evidence requirements should be agreed before the evaluation begins.
Start with the business decision
Use a 30-minute conversation to identify the issue, decide whether a direct Comply discussion or a separately scoped assessment fits, and agree on the next step.