Autonomous requests enter through a governed boundary instead of calling tools, channels, APIs, or enterprise systems directly.
Architecture
How Atellagent governs AI execution.
Atellagent applies one governed execution path across hosted and external runtimes, models, tools, channels, and enterprise systems. Every action request is authenticated, authorized, policy-evaluated, and recorded before downstream execution proceeds.
Atellagent is a governed execution platform built on a shared control architecture.
The architecture exists to keep AI-driven work on one governed decision path from request to side effect, instead of leaving runtime execution, policy checks, and review scattered 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.
Hosted and external runtimes traverse the same execution boundary.
The architecture keeps identity, policy, and evidence attached before requests reach tools, channels, MCP servers, APIs, or data stores.
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.
Three participation forms share the same control boundary.
- Atellagent owns the execution loop.
- Identity, authorization checkpoints, policy evaluation, and evidence stay first-party by default.
- This is the strongest built-in control posture.
- Atellagent governs the contract while translating to an external runtime.
- Existing customer-hosted runtimes can remain in place.
- This is the cleanest way to preserve existing execution while standardizing control.
- 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 an adapter process.
Every action request traverses the same governed execution path.
action request
-> authentication
-> authorization
-> policy evaluation
-> evidence collection
-> allow, deny, narrow, or request approval
-> bounded execution
-> attributable outcome evidence
Autonomous requests enter through a governed entry point instead of calling downstream systems directly.
Each participant acts through authenticated identities and bounded authority rather than ambient runtime access.
Actions are evaluated against identity, context, approvals, and policy rather than static permissions alone.
Approved actions execute through bounded runtime surfaces, and the decision record stays tied to resulting outcomes for later review.
The architecture answers a stricter question than access control alone: should this action be allowed right now under enterprise policy?
The same decision path applies whether the action originated in Atellagent's hosted runtime or an external runtime participating through adapter or SDK forms.
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.
Some failures only state can catch.
Individually safe actions can become unsafe in aggregate once workflow state, prior approvals, and earlier decisions are considered together.
Data, permissions, and meaning can change across multi-step execution paths, so a later step may need different policy outcomes than an earlier one.
Parallel checks can both pass unless reservation, coordination, and current state are explicit at decision time. That is how oversubscription and race-condition failures slip through simpler controls.
Deterministic policy and learned scoring serve different roles.
- 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.
- ML detectors provide risk, model-security, or content-security signals.
- Those signals can inform review, narrowing, approvals, or response-side checks.
- The architecture supports both without collapsing one into the other.
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.
Operators can inspect and reconstruct what happened without relying on disconnected logs or expiring raw traces alone.
The same control logic spans managed and customer-hosted execution.
- Hosted
- Private cloud
- On-prem
- Mixed hosted and external runtime participation
- Governed ingress, authentication, and authorization
- Policy evaluation and bounded execution
- Decision-linked evidence and review continuity
Want to review this boundary in your environment?
Book a technical review to walk through deployment boundaries, runtime forms, policy enforcement, identities, and evidence.