HomeArchitectureEvidenceConnectorsUse casesContact
Architecture / Control Contract

Authority before effect.

OBEAX separates agent intent from execution authority. The system does not ask only whether an agent can call a tool; it asks whether this specific action, in this state, for this tenant and target, is authorized now.

Any Agent
OBEAX Trust Core
Connector Control Plane
→ Any Controlled System
IdentityStatePolicyAuthorityApprovalExecution AuthorizationExecuteVerifyAudit / Evidence
01 / Pipeline

Each stage narrows what can happen next.

Identity

Resolve the authenticated human, service or AI-agent principal from server-controlled context.

State

Bind the action to durable state so execution cannot float free of lifecycle history.

Policy

Derive trusted policy independently from caller attempts to weaken or strengthen outcome.

Authority

Check delegated capabilities, scope, target, validity and revocation.

Approval

Derive approver identity server-side and separately verify approval authority.

Execution authorization

Revalidate conditions close to the effect; stale authority should fail closed.

Execute

Call only through bounded connector execution roots rather than direct privileged access.

Verify

A 200 OK acknowledgement is not completion. Read back the target state when supported.

Audit / Evidence

Record what was requested, authorized, executed and independently confirmed.

02 / Connector Model

Connectors extend reach. They do not define authority.

Agent connectors

MCP, A2A and native agent runtimes.

Context connectors

Read-only context and data sources.

Identity connectors

OIDC, OAuth, SAML, workload identity and service principals.

Policy feeds

External rules and control inputs.

Approval channels

Teams, Slack, portals, service workflows.

Execution connectors

OpenAPI, gRPC, cloud, SaaS, ERP, OT gateways.

Result verification

Read back intended post-condition before completion.

Evidence sinks

SIEM, WORM, immutable object stores and auditor export.

03 / Operating Modes

A connector should be promotable, not simply on or off.

MODE 01

OBSERVE

Collect context and evaluate without downstream execution.

MODE 02

SHADOW

Run the full OBEAX decision path but suppress the real downstream effect.

MODE 03

ENFORCE

Permit controlled real execution only after the required release and security gates pass.

04 / Action Contract

Every action needs machine-readable effect semantics.

connector_id
connector_version
target_system
action_key
protocol
tenant_scope
principal_type
auth_method
required_capability
effect_class
risk_class
reversibility
idempotent
dry_run_supported
shadow_supported
approval_floor
timeout
retry_policy
network_egress
secret_reference
input_schema
output_schema
precondition_check
postcondition_check
evidence_requirements
compensation_action
05 / Completion

No completion without verified post-condition.

When a target supports it, OBEAX should treat an API acknowledgement as an intermediate event. Completion means the intended target state was independently read back and matched to the authorized post-condition.

REQUESTAUTHORIZEEXECUTEACKREAD BACKVERIFYCOMPLETE
06 / Reversibility

Not every effect can be undone.

CLASS A

REVERSIBLE

The action can be restored to the prior state with a defined inverse.

CLASS B

COMPENSATABLE

The original event remains, but an explicit compensation can mitigate the outcome.

CLASS C

IRREVERSIBLE

The effect cannot be reliably undone; policy and approval floors should reflect that.