Runtime integration verified in fixture · 15 September 2026

Architecture and runtime integration

Scope

Define ownership and integration boundaries. The dashboard presents information and transports commands. The independent Agent Mate host owns task coordination. The existing AIOS runtime performs model turns and tool execution. Connections supplies authorization; the proposed MCP bridge enforces access to external tools.

The diagram shows the proposed complete path. The scoped MCP adapter is not operational yet.

Existing foundation

The reviewed Agent Mate runtime adapter launches aios tui-backend, creates or resumes a session, and submits through prompt.submit. AIOS loads configured MCP tools at runtime-process startup. The headless host exists separately from the dashboard.

Decisions

• The harness remains unchanged. No alternative agent/model execution loop.
• Do not use browser-connection lifetime as task lifetime.
• Bind account, immutable project, task and runtime session before admitting tool operations.
• MCP calls stay on the existing runtime tool path; a bridge handles protocol and permission enforcement.
• A project name, prompt instruction or working directory alone is not an isolation boundary.

Questions to resolve

How can the supported startup configuration expose only a task's scoped bridge without copying a dashboard home or provider keys? How does the bridge authenticate a project when multiple workers share a Linux identity? What refresh mechanism can safely expose newly granted tools?

Implementation tasks

Acceptance evidence required

A disposable tool must be invoked by the actual existing runtime. A second project cannot impersonate the first. Closing the dashboard must not kill the task. Confirm no harness changes. Current evidence is source review and the earlier independent-host handoff, not a completed scoped-runtime test.

Related areas

• Agent Mate overview — A guide to the separate designs and how they fit together.
• Connections, credentials, and permissions — Shared connection ownership, project grants, key handling and revocation.
• Execution, recovery, and progress tracking — Independent tasks, cancellation, uncertain outcomes and durable progress.
• Project-scoped MCP for Agent Mate — The existing seven-task MCP plan: grants, bridge integration, revocation and acceptance.

MCP-P01 progress — actual runtime proof

On 15 September 2026, an executable rmcp3.4 fixture ran through the existing shadow AIOS binary, using session.create and prompt.submit. A deterministic loopback model responder requested the MCP tool; no real provider or project was contacted.

This proves runtime/protocol compatibility and per-call denial behavior in a controlled fixture. It does not prove hostile-worker isolation, multi-account ownership, concurrent projects, or real Connections grant enforcement. Launch arguments and the fixture policy are supervisor-controlled test inputs, not a production identity mechanism. MCP-P01 remains in progress.

The next implementation requirement is a trusted account/project/task binding and policy boundary outside the worker's writable filesystem. The current host is single-owner and authenticates Unix peers by UID; that alone cannot distinguish multiple projects. Do not enable live project MCP access until this boundary is implemented and verified. Harness source and live services were not changed by the proof.

Authenticated submission wiring and worker storage checks

Implemented in the development dashboard: before a scoped Agent Mate send reaches the host, the adapter resolves the logged-in account, checks its server-configured host and project mapping, and persists the task binding in the authority-owned Connections registry. It uses the same deterministic project selection as Agent Mate. Extra identity fields in the command are rejected. Session identity and host assignment are rechecked before dispatch.

The opt-in task configuration is private, owned by the dashboard authority, and requires a different worker Linux UID. Absence of configuration preserves ordinary chat and creates no project MCP binding. This is not implicit permission to use MCP. The policy mapping is operator-controlled; it is not a browser-editable account or host selector.

Verification completed

• A real compiled dashboard accepted a disposable authenticated WebSocket send and created Alice's host/project binding before the synthetic Unix host received it.
• Forged owner fields, another account's project and stale revisions did not reach host execution.
• Same-UID worker configuration and non-private policy files were rejected.
• Removing the fixture session closed its existing socket.
• An installation without scoped configuration retained ordinary chat with zero MCP task bindings.
• In the running shadow worker's mount namespace as UID994, eight read/write attempts against an authority-only sentinel failed, including direct paths and paths through the dashboard process's root. The authority UID995 could read it. Sentinel removed afterwards.
• Existing MCP WebSocket management fixture passed. Four Agent Mate library regressions passed. Earlier Connections suite passed32 tests.

The dashboard test uses a synthetic Unix host to observe dispatch order; the separate runtime proof uses the actual AIOS execution loop. These do not yet establish a complete real-provider, multi-project bridge flow. The worker storage check enters the actual mount/UID boundary but does not inherit the service cgroup/seccomp filters.

Deployment state

Tested build is staged, not activated. The shadow deployment guard found two dashboard-owned AIOS processes and prevented their interruption. No live project grants, task configuration, runtime restart, production changes or harness edits were made. Deployment can use the existing guarded activation script once the dashboard has no active child processes. No new approval is requested.