3LS Platform / Browser and MCP Controls

Bring supported browser and tool workflows under policy.

Apply configured policy at supported browser and managed MCP integration points. Give users and operators a clear decision and retain evidence of the action taken.

Browser workflows

Help users recognise a policy decision at the point of interaction.

Inspect selected prompt text on supported ChatGPT and Claude sites. Conversation-history inspection depends on the configured policy. Upload controls use file metadata, not file contents. Available feedback and actions depend on the site, selected fields and configured integration.

Configured browser interaction · conceptual flow
  1. Supported site / selected prompt text
  2. Configured assessment and policy
  3. User feedback and bounded decision evidence

This is a supported site interaction. It does not depict browser response or file-content inspection, or control of arbitrary client/harness tool execution.

Managed MCP workflows

Make the dispatch decision before the supported backend call.

Review observed MCP installations and tool revisions, configure approved tool groups and inspect original arguments before backend dispatch. Supported managed paths can hold an action for acknowledgement or approval, retaining the policy and action decision.

Supported managed MCP path · two different decision points

Original arguments before dispatch

  1. Client / original tool arguments
  2. Argument gate / configured approval
  3. Backend may execute a permitted call

Denied or held operations do not proceed to the backend on the supported managed path.

Returned result after execution

  1. Backend action already executed
  2. Selected result fields inspected
  3. Permitted result delivered to client

Result inspection happens after execution and before returned-result delivery. Result denial cannot undo an effect already executed. Direct backend access and backend-added behaviour require separate controls.

Give the operator a readable decision and response path

Review the applicable policy, action class, decision, approval state and available outcome records. Keep task/activity classification, risk signals and action permissions separate. Assign an owner to an issue, record the response and retain remediation evidence.

The records above are independent illustrative examples. They do not imply a complete cross-channel causal history or automatic case creation. Central records use bounded metadata, hashes and redacted fields rather than the raw local prompt shown in the browser example.

Explore Compliance and Assurance →

A tool proposal and a backend call have different boundaries

The gateway page describes checking a model-proposed tool call before delivery to the harness. Managed MCP argument checks here act before backend dispatch; returned-result inspection happens after backend execution. Confirm which integration applies to each step in your workflow.

Tool security before the harness →

Agree the supported integration for your environment

Discuss supported sites and clients, selected fields, policy feedback, tool groups, approval handling, identity and evidence retention. Confirm installation, persistence and enrollment availability for the chosen deployment and how policies are applied.