Skip to content

How policy governs execution.

Requests, permitted operations and recorded outcomes stay connected. The enforcement boundary depends on whether Atellagent runs the code or connects to an external agent.

Authority follows the task.

Policy governs what hosted code may do throughout execution. Starting a task does not preauthorize later actions; task state, approvals and required evidence still matter.

From request to result.

  1. Request

    An agent or workflow requests an action in the context of its task.

  2. Check

    Policy considers identity, current task state and required evidence.

  3. Enforce

    The governed boundary applies the permitted scope and records the result when available.

Native host hooks cover the events their hosts report. They do not place every agent action on an Atellagent execution route.
On this page

Choose how to connect.

Hosted execution

Workflows govern dispatched actions. Hosted coding also constrains protected file, network and credential operations as code runs.

Governed MCP tools

Model Context Protocol (MCP) connects tools to agents. Atellagent checks calls on its governed MCP routes.

Your own agents

Use the Client SDK, a bridge, or supported host hooks. Coverage follows that integration's documented contract.

Enforce at your MCP server.

Enterprise MCP extends the connected MCP runtime with a direct intake at your server. Calls through Atellagent carry verified authorization. A direct caller authenticates with your server, and the same runtime requests a central policy decision before executing its mounted tool handler.

The enrolled server's credential identifies the reporting boundary. A verified caller identifier remains separate, scoped to its issuer and account. Provider tokens stay local. Policy evaluates the published tool and exact arguments; a failed required authorization prevents execution. No synthetic workflow is needed.

Direct clients are blocked by default. The current managed setting is checked centrally on direct admissions and required release. Turning it off blocks new direct work; it cannot undo completed effects. Protection requires every covered tool dispatch to pass through the handler.

Review Enterprise MCP

Require evidence before proceeding.

A policy can require a successful earlier action or an approval. Work proceeds only when the required evidence is present.

Action checks

Rules consider identity, target, approvals, required prior-action records, and workflow state. They can allow, deny, constrain, or pause eligible hosted work for approval.

Data checks

Configured content controls consider the data, destination, and action before a supported release to a model, tool, channel, service, or agent.

In Enforce mode, a governed route releases only the permitted action. Observe mode records policy decisions without blocking on organization-authored policy effects.

What policies can cover.

Available controls depend on the supported route and configuration.

Workflows
Steps, state, and approvals.
Agents and tools
Agent communication, tool calls, and governed MCP actions.
Models and content
Model access and configured data-protection checks.
Channels
Supported inbound and outbound channel actions.
Memory and context
Access tied to the requesting identity and policy.

Rules decide. Detectors supply evidence.

Deterministic rules decide whether an action is allowed. Built-in detectors and customer classifiers can supply content or risk signals at supported boundaries. Their findings cannot override a denial or publish a policy.

Semantic Review adds context.

When enabled, a model assesses applicable actions and returns risk evidence for the rules to evaluate. Enforce evaluates before release; Observe records nonblocking evidence.

Add review criteria in plain language alongside standard risk checks. They guide the assessment and are not compiled into deterministic rules.

Configured deterministic policy decides whether to deny an action or request eligible hosted approval. In Enforce mode, policy can deny a triggered external action; eligible hosted actions can instead be paused for human review.

Assessment limits

The assessor receives a bounded, server-built action description linked to the exact action. Provider-bound content passes through configured data-protection controls.

It returns a validated score, factors, coverage indicators, and justification. It cannot call tools, access memory, execute or rewrite actions, create approvals, or read or write policy.

Choose a supported model and reasoning level. Atellagent defines the rubric, input limits, response validation, and policy integration.

You review and save the policy.

The authoring assistant uses approved templates to prepare a proposal. It cannot publish a policy on its own.

  1. Describe the rule you need.
  2. Review the proposed rule and scope.
  3. Validate the final proposal.
  4. Save it through the policy publication controls.

Review the request and its result.

Decision records link the requested action to its identity, policy, approvals, and available detector evidence. Recorded outcomes can then supply evidence for later policy checks.

If a native host does not report a post-tool result, the outcome remains explicitly unobserved. A missing result does not prove success.

Combine hosted and external agents.

Use hosted workflows, supported external integrations, or both. They share central policy; each connection retains its own execution and reporting limits.

See Agent DLP for data controls and Integrations for connection setup and coverage.

Review your setup with us.

Discuss connection types, policy checks, and reporting limits.