Forem: Alexander Shishenko

ACT 0.7: sessions, three production bridges, and auth-via-args

Alexander Shishenko — Sun, 10 May 2026 16:00:00 +0000

The previous posts focused on what ACT is — sandboxed components, one
binary per transport, capability ceilings. This one is about a thing
that was missing: state.

Most of the components on actpkg are pure request/response — crypto,
encoding, random, time. They don't need a session because every
call is independent. But the moment you reach for tools that do —
a database connection, an OpenAPI client that has parsed a 5MB spec, an
MCP bridge mid-handshake with an upstream server — there's nowhere to
put that state. Components held it in thread_local! HashMaps keyed by
std:session-id metadata, and the host had no idea what those ids
meant or when to clean them up.

ACT 0.7 fixes that. Stateful components now opt into a small new WIT
interface, act:sessions/session-provider@0.1.0. The interface is
deliberately tiny — three functions — and it changes nothing for the
80% of components that don't need it.

The interface

package act:sessions@0.1.0;

interface session-provider {
  use act:core/types@0.4.0.{metadata, error};

  record session {
    id: string,
    metadata: metadata,
  }

  /// JSON Schema describing valid args for `open-session`.
  /// Hosts use this to validate before they invoke the component.
  get-open-session-args-schema: async func(metadata: metadata)
    -> result<string, error>;

  /// Open a session. `args` carries connection params and credentials.
  open-session: async func(args: metadata, metadata: metadata)
    -> result<session, error>;

  /// Polite shutdown — sync, advisory. The host MUST call this for
  /// every session it opened, before component deinit.
  close-session: func(session-id: string);
}

Subsequent capability calls (tool-provider.list-tools,
tool-provider.call-tool) pass the returned id as std:session-id
in their metadata. The component does its own state lookup. The host
keeps the wasm instance alive as long as it's serving sessions, and
closes whatever's still open before it tears the instance down.

If you used the old metadata = {"url": "..."} shape on the bridges,
this is a breaking change. The reasoning is in the next section.

Three bridges, rebuilt

The whole reason act:sessions exists is that bridges need it. Three
of them just shipped on the new model:

`mcp-bridge` 0.2.0

Wraps a remote MCP server, exposes its tools as ACT tools.
open-session does the MCP initialize + notifications/initialized
handshake against the upstream and stashes the resulting
Mcp-Session-Id header for the lifetime of the session. The bridge
issues its own outward-facing id and maps the two NAT-style — agents
never see the upstream's id, so swapping upstream-session-ids on
expiry is invisible from the agent's side.

act run ghcr.io/actpkg/mcp-bridge:0.2.0 --mcp
# then, agent: open_session({"url": "https://upstream.example/mcp", "auth_token": "sk-..."})
#         →  {"id": "mcp_0", "metadata": {}}
# then, agent: tools/list with _meta.std:session-id = mcp_0

`openapi-bridge` 0.2.0

Loads an OpenAPI 3.x spec at runtime and exposes each operation as a
local ACT tool. open-session({spec_url, headers}) fetches and parses
the spec eagerly, so connect or parse failures surface at open time
rather than 17 tool calls later. Path/query/header parameters and
JSON request bodies are flattened into a single tool argument schema,
auto-named from operationId (or synthesised from method + path).

The parsed spec is cached by spec_url so multiple sessions targeting
the same API share the parse — opening 10 sessions for the same spec
costs one fetch.

`act-http-bridge` 0.2.0

The simplest of the three. Proxies a remote ACT-HTTP host as local ACT
tools. open-session({url, headers}), then any list-tools /
call-tool is forwarded to the upstream component over HTTP. Useful
when you want one local component to delegate to a fleet of remote
ACT components without mounting all of them in your host config.

Auth lives in open-session, not metadata

Until 0.7, mcp-bridge accepted auth_token as metadata on every
call. That was wrong on three counts.

Auth is per-session, not per-call. Once you've authenticated to
the upstream, every subsequent call within that session uses the same
identity. Stuffing the bearer into every tools/call is duplication
and a bug surface — what if some client puts it in some calls and not
others?

Auth has a schema. OAuth wants a token. HTTP basic wants a
username and password. mTLS wants a key and cert. Different per-component.
open-session.args is component-defined, validated by the host
against the schema returned from get-open-session-args-schema before
the credentials ever touch the wasm. There's no place in metadata
to carry that schema.

Auth lives at one boundary. With session args, the bearer flows
once: host configuration → host validation → wasm via open-session.
After that, the agent only ever sees the opaque session-id. If the
session-id leaks, the agent gets capability the operator already
granted. If the bearer leaked from per-call metadata, the agent —
or whoever observed metadata in transit — would have the upstream
credential itself.

Full guidance is in
ACT-AUTH.md.

Transport plumbing

The host exposes session lifecycle on the wires it already speaks.

ACT-HTTP gains three endpoints (per
ACT-SESSIONS §6.2):

POST  /sessions/open-args-schema   → JSON Schema (metadata in body)
POST  /sessions                    → 201 with session record
DELETE /sessions/{id}              → 204

Subsequent capability calls reference the session via std:session-id
in request body metadata or the X-Act-Session-Id header.

MCP synthesises two virtual tools whenever the underlying
component exports session-provider — open_session and
close_session, with _meta.std:session-op annotations so agents
recognise them as lifecycle ops, not ordinary capabilities. The agent
calls open_session once, threads _meta.std:session-id into every
subsequent tools/call, and finally calls close_session. The host
also forwards any _meta keys from the agent into the WIT call
metadata, so std:session-id reaches the component without any
host-side translation.

ACT-CLI picks up a new flag, act call --session-args. The host
opens a session, threads the returned id into the call's metadata as
std:session-id, runs the tool, and closes the session — all in one
process, so the wasm instance stays alive for the full sequence.

A self-contained demo: serve the time component locally, then
proxy through act-http-bridge and call it through the proxy.

# Terminal 1 — upstream ACT-HTTP server.
act run ghcr.io/actpkg/time:0.2.0 --http -l '[::1]:3000'

# Terminal 2 — one-shot call through the bridge.
act call ghcr.io/actpkg/act-http-bridge:0.2.0 get_current_time \
  --args '{}' \
  --session-args '{"url":"http://[::1]:3000"}' \
  --http-policy open
# 2026-05-07T12:00:00.000+00:00

The bridge instance opens a session that owns the upstream URL, calls
get_current_time through it, closes the session, and exits. With an
openapi-bridge instead of act-http-bridge and --session-args '{"spec_url":"..."}' instead of {"url":"..."}', the same shape
works for any OpenAPI 3.x spec.

act session open-args-schema is also still there for inspecting a
component's session args. Earlier 0.7.0 shipped act session open and
act session close as separate subcommands, but those were useless:
each invocation is a one-shot process whose wasm instance dies on
exit, so a session opened in one process is unreachable from a later
call. They were removed in 0.7.1, and --session-args replaces
both of them with the right shape — the open/call/close cycle in one
process — in 0.7.2.

SDK ergonomics

For Rust components, the new
#[session_open] / #[session_close]
markers on top of act_sdk::SessionRegistry<T> keep the boilerplate
small:

use act_sdk::prelude::*;
use act_sdk::SessionRegistry;

#[act_component(name = "counter")]
mod component {
    use super::*;

    pub struct Counter { value: u64 }

    thread_local! {
        static SESSIONS: SessionRegistry<Counter> =
            SessionRegistry::new("ctr");
    }

    #[derive(Deserialize, JsonSchema)]
    struct OpenArgs {
        #[serde(default)]
        start: u64,
    }

    #[session_open]
    fn open(args: OpenArgs) -> ActResult<String> {
        Ok(SESSIONS.with(|r| r.insert(Counter { value: args.start })))
    }

    #[session_close]
    fn close(id: String) {
        SESSIONS.with(|r| { r.remove(&id); });
    }

    // Tools read std:session-id via ActContext<MetaStruct>.
}

The macro derives get-open-session-args-schema from OpenArgs via
schemars, decodes the metadata-shaped wire args into the typed
struct, and emits the full session-provider Guest impl. The full
runnable example is
examples/sessions-counter.

Components with dynamic tool catalogs — every bridge — currently
hand-roll wit_bindgen::generate! because #[act_component] only
emits a static list-tools from #[act_tool] declarations. That's a
known gap; an SDK-side affordance for dynamic catalogs is on the list.

What's next

Host-side OAuth. ACT-AUTH describes how a host reads x-act-authorization-server and x-act-scopes annotations on the open-session schema, runs the OAuth flow, and injects the bearer into args before calling open-session. The annotations are spec'd; the host implementation isn't there yet.
Auto-open from host config for --mcp / --http. act call now opens / closes per-invocation via --session-args, but for the long-running transports the agent still has to call open_session itself. For "I always want this OpenAPI / MCP server / API" configurations, the host should pre-open the session at startup from config, so the agent sees ordinary tools and never thinks about the session at all.
Postgres component. A component that authenticates via open-session.args, holds a real connection through the session, and does parameterised queries through the tools. Not ready yet — this'll be the first non-bridge stateful component on actpkg.
SessionContext<T> SDK sugar. Drop the ToolMeta { #[serde(rename = "std:session-id")] session_id } boilerplate components currently write to read the session-id.

If you've got an OpenAPI spec, a remote MCP server, or an internal
ACT-HTTP fleet, the bridges are running on ghcr.io/actpkg ready for
act run --mcp. If you want to write a stateful component yourself,
the sessions-counter
example
is the smallest working template. Issues, ideas, and "this looks like
what I'd want for X but Y is missing" reports are welcome at
github.com/actcore.

MCP servers, sandboxed — introducing ACT

Alexander Shishenko — Fri, 08 May 2026 17:01:35 +0000

Setting up an MCP server for your AI agent today usually looks like this:

npx -y @some-org/mcp-server # or
uvx some-mcp-server # or the occasional
curl https://example.com/install.sh | bash

The server runs as you. It can read your home directory. It sees your SSH keys, your .env files, your shell history, your browser cookies, your GPG keyring. If the server has a bug — or a malicious dependency sneaks in — the code that reads those files also runs as you. If your kernel or any installed binary has an unpatched local privilege escalation, the agent-invoked tool just inherited that escalation path too.

That isn't a failure mode of any particular MCP server; it's the default deployment model. Ambient-permission native processes, shipped by anyone, invoked on demand by an LLM that's notoriously easy to talk into misusing them."Your agent has your credentials and runs strangers' code on request" is the baseline security posture of every MCP setup built on npx / uvx / curl | bash today. It's a full-blown security nightmare that the industry has collectively decided not to look at.

ACT — Agent Component Tools — is the model that looks at it.

Every ACT tool is a WebAssembly component running inside wasmtime — a full VM with a JIT, linear memory, and no ambient host syscalls. Out of the box the component has zero filesystem access, zero outbound network, and no way to spawn a process. Each capability it does use (wasi:filesystem, wasi:http) is declared in the component manifest at build time and granted by the operator at run time. The host enforces the intersection: a permissive operator can't escalate past the component's stated intent, a lazy component can't silently exceed the operator's grant. You hand a tool from ghcr.io/someone-else/whatever to your agent, and the worst-case blast radius is still bounded by the policy you wrote.

That's the core trade ACT offers. The rest of this post is about why the WebAssembly-component substrate makes it practical.

Distribution, for free

A side benefit of picking WebAssembly: the artifact is a single binary that runs everywhere.

act info ghcr.io/actpkg/random:latest --tools

That command pulls a small component from GitHub's container registry, reads its metadata from a WASM custom section (no instantiation), and prints the tools it exposes. First pull is cached, every subsequent invocation hits the local ~/.cache/act/components. The artifact is signed by GitHub's attestation workflow and comes with an SBOM — all upstream machinery; ACT just uses it.

Same bytes, same SHA256, on Linux x86_64, macOS arm64, Windows, Android (validated), Raspberry Pi, inside a browser tab, inside a serverless runtime. No per-platform wheels, no native shims, no build toolchain required on anyone's machine but yours. And because the artifact is a registry object rather than three separate npm/pip/cargo packages, there's one supply-chain path to audit instead of three.

act accepts components from any of:

local path: ./my-component.wasm
HTTP URL: https://example.com/tool.wasm
OCI ref: ghcr.io/your-org/tool:1.2.3

No "my-tool-npm" and "my-tool-pypi" and "my-tool-cargo". One artifact. One namespace.

How the sandbox actually works

The isolation comes from three stacked layers, and it's worth separating them because "WASI sandbox" isn't quite the right phrase.

wasmtime is the actual isolation. It's a WebAssembly VM: linear-memory bounds enforced, no direct syscalls, no pointer aliasing, no escape outside of explicit host imports. Every ACT target runs the same wasmtime, so the isolation is identical on every OS and CPU.

WASI is the capability-import layer on top. A component asks for wasi:filesystem or wasi:http imports; the host either wires them up, provides a gated proxy, or leaves them unlinked. There's no "deny" at the capability level — a component either has the import or it doesn't.

ACT is the policy layer on top of WASI. Filesystem and outbound network are deny-by-default. The component's manifest declares what it needs ([std.capabilities."wasi:filesystem"], "wasi:http") — this is a ceiling. The operator's runtime flags (--fs-allow /tmp/db.sqlite, --http-allow host=api.example.com) are the grant. The host computes the intersection and refuses to wire up anything outside it.

Deny-CIDR rules sit in front of DNS resolution, so a component that tries to reach 169.254.169.254 (the cloud-metadata service) fails with a DnsError before a socket opens. HTTP redirects are re-checked per-hop, so a 302 to a denied host fails mid-chain instead of quietly succeeding. Details are in the capability-layer deep-dive (next post).

The VM gives us isolation. WASI gives us capability imports. ACT gives us the declaration-plus-ceiling model that makes those capabilities safe to hand to third-party code.

One component, any transport

Because tools are components, not native processes, the host can serve them over whatever wire format the caller wants.

# Claude Desktop / Cursor / Cline → stdio JSON-RPC
act run ghcr.io/actpkg/sqlite:latest --mcp \
  --fs-policy allowlist --fs-allow /tmp/demo.sqlite

# Web backend → REST-ish HTTP with SSE streaming
act run ghcr.io/actpkg/sqlite:latest --http --listen "[::1]:3000"

# Script / CI → one-shot direct call
act call ghcr.io/actpkg/sqlite:latest query \
  --args '{"sql": "SELECT sqlite_version()"}' \
  --metadata '{"database_path":"/tmp/demo.sqlite"}'

# Browser tab → jco transpile, no server at all
jco transpile ghcr.io/actpkg/sqlite:latest -o dist/

Same component, same tool, four deployments. Whatever new transport shows up next, the component doesn't change.

Writing one

Rust, the whole SDK surface for a trivial tool:

use act_sdk::prelude::*;

#[act_component]
mod component {
    use super::*;

    #[act_tool(description = "Reverse a string", read_only)]
    fn reverse(text: String) -> ActResult<String> {
        Ok(text.chars().rev().collect())
    }
}

cargo build --target wasm32-wasip2 --release + act-build pack and you have a .wasm that speaks MCP, HTTP, and the CLI. #[act_tool] derives the JSON Schema from the function signature; #[act_component] emits the WIT export. Python has the same shape with @component / @tool decorators on top of componentize-py.

Where this is

Early, and deliberately narrow.

The core spec lives in actcore/act-spec — a small WIT package for cross-cutting types and an opt-in interface package for tool dispatch, with stateful capabilities (sessions, events, resources) layered on as separate opt-in packages. The host ships as act on npm, cargo, and PyPI. A growing set of components is published on ghcr.io/actpkg — sqlite, http-client, crypto, encoding, filesystem, openwallet, python-eval, js-eval, random, time, plus three bridges (mcp-bridge, openapi-bridge, act-http-bridge). Rust and Python SDKs are live; JavaScript via componentize-js is blocked on upstream async-export support.