Autonomous requests enter through a governed boundary instead of calling tools, channels, APIs, or enterprise systems directly.
How Agent Authority governs AI execution.
Atellagent Agent Authority applies one governed execution path across hosted and external runtimes, models, tools, channels, and enterprise systems. Every action request entering through an Atellagent-hosted runtime or configured integration is authenticated, authorized, policy-evaluated, and recorded before downstream execution proceeds.
Connect authority, policy, and evidence to each outcome.
Agent Authority keeps the identity, decision basis, and resulting outcome together, rather than scattering runtime execution, policy checks, and review across separate systems.
Authentication, authorization, policy evaluation, and evidence collection are evaluated together before execution proceeds.
Allowed, denied, narrowed, and approved actions remain linked to the resulting outcome for review, audit, and follow-up.
Keep identity, policy, and evidence on the route to the side effect.
The runtime mesh connects participating execution paths before requests reach tools, channels, MCP servers, APIs, data stores, or enterprise systems, so one allowed action does not turn into broad downstream reach.
Every runtime form passes through the same secure runtime mesh, where identity, policy, and evidence remain in the execution path before action requests become side effects.
Choose how each runtime participates.
- Atellagent owns the execution loop.
- Identity, authorization checkpoints, policy evaluation, and evidence stay first-party by default.
- This provides the most direct built-in enforcement and observation boundary.
- External hosts participate through documented client hooks or supported adapters.
- Existing customer-operated runtimes can remain in place where the integration contract supports them.
- Observation and enforcement coverage follows the host lifecycle events and boundary it exposes.
- An existing process embeds governed outbound calls directly.
- The runtime keeps its own execution machinery while participating in Atellagent control contracts.
- This is useful when teams want direct integration without standing up a separate adapter process.
Every action request traverses the same governed execution path.
Authority is never inferred from a runtime, network location, or earlier request. Each governed action is authenticated, bound to request-scoped authority, evaluated against current policy, and recorded before it can proceed.
action request or supported data-release request
-> authenticate participant and bind request-scoped authority
-> deterministic precheck and bounded evidence collection
-> final deterministic policy evaluation
-> allow, deny, narrow, or request approval
-> bounded execution
-> attributable outcome evidence
After request-scoped authority is bound, policy answers whether a requested tool call, workflow step, channel action, or other governed side effect may proceed under its current identity, target, approval context, required prior-action receipts, and current workflow state. Semantic Action Review can add bounded risk evidence and require exact-action human review without becoming the authorization authority.
For data release, content-control evidence is evaluated alongside destination and action context before a model, tool, channel, service, or external-agent release proceeds.
One control model spans more than one kind of request.
Workflow execution, workflow state, approvals, and step-level constraints stay inside the same policy model.
Agent communication, governed tool calls, and MCP-backed execution surfaces are evaluated through the same control path.
Model access, content-security checks, and detector-informed controls participate in the same governed decision flow.
Inbound and outbound channel actions can stay on the same control boundary instead of bypassing runtime controls.
Memory access and execution context can stay attributable to the same identity, authority, and policy envelope.
These surfaces do not create separate governance systems. They share identity, authorization, evidence, and review continuity.
A governed tool path can allow the right tool call while still constraining which files, destinations, or execution surfaces that action is allowed to touch.
The job is not finished once a request is allowed. Approved work still stays inside bounded routes on the way to the side effect.
Industry-standard policy remains authoritative; detector evidence is bounded input.
- Deterministic policy handles allow, deny, and control logic.
- Policy domains can be selected by action type and runtime context.
- Denies and platform invariants remain authoritative.
- Built-in detectors and customer-provided classifiers provide risk or content-control signals at supported boundaries.
- Those signals can inform review, narrowing, approvals, or release-side checks.
- A detector result never independently overrides a deterministic deny or publishes policy.
Assess action meaning and context without handing authority to a model.
canonical governed action + immutable fingerprint
-> deterministic precheck
-> minimal server-built action projection
-> governed semantic-risk assessment
-> validated evidence
-> final deterministic policy evaluation
-> dispatch or exact-action human review
- Every canonical governed action is assessed at action admission.
- The assessor receives a minimal server-built projection, not unrestricted policy input, source code, memory, credentials, or raw infrastructure context.
- It returns a validated rubric score, bounded factors, coverage indicators, and a short justification as evidence.
- Deterministic policy decides whether risk evidence requires review; a semantic score never directly creates a hard denial.
- In enforce mode, elevated risk, unavailable evidence, or incomplete coverage routes the exact action to accountable reviewers.
- The assessor cannot call tools, access memory, execute or rewrite actions, create approvals, or read or write policy.
Administrators select a supported model and reasoning level through the standard product controls. Atellagent owns the fixed rubric, input projection, structured-output contract, validation, and policy integration.
Evidence is linked to the governing decision, not bolted on later.
Identity, authorization path, policy path, runtime state, approvals, and detector signals are preserved with the governed decision.
The execution context remains attributable to the action and approval path that allowed it.
The system preserves what was requested, not just the side effect that eventually occurred.
Resulting external effects and response-side outcomes remain attributable to the governing decision record.
Teams can understand what happened without relying on disconnected logs or incomplete traces alone.
The control model spans hosted workspaces and supported external participation.
- Atellagent-hosted workspaces and workflows
- Supported external agent hosts through the public client
- Mixed hosted and supported external participation
- Governed ingress, authentication, and authorization
- Industry-standard policy evaluation and bounded execution
- Decision-linked evidence and review continuity
For the product-level boundary and coverage details, see Agent DLP and Integrations.
Want to review this boundary in your environment?
Book a technical review to walk through deployment boundaries, runtime forms, policy enforcement, identities, and evidence.