DOCSEARCHbyAlgolia
Submit Docs

ACT (Agent Component Tools)

website·Indexed 30 days ago

https://actcore.dev

A protocol for packaging AI agent tools as sandboxed WebAssembly components. ACT provides a hardened toolchain featuring capability-based security, signed artifacts, and a CLI for running components over MCP (Model Context Protocol), stdio, or HTTP. It includes SDKs for Rust and Python, a browser runtime via @actcore/web-runtime, and a component registry at actpkg.dev.

Tokens
22.4K
Snippets
111
Records
178
Agent score
61%

What's inside ACT

  1. Overview of ACT (Agent Component Tools)

    ACT is a security-focused model for deploying MCP (Model Context Protocol) servers. Unlike native processes that run with ambient permissions, ACT tools are WebAssembly components running inside the wasmtime VM. This ensures isolation with no direct host syscalls, linear-memory bounds, and a deny-by-default security posture. Capabilities (like filesystem or network access) must be declared in the component manifest at build time and granted by the operator at runtime; the host enforces the intersection of these two requirements to prevent privilege escalation.

  2. Overview of actcore WIT packages

    The WIT (WebAssembly Interface Type) serves as the source of truth for the actcore protocol. All JSON Schema, OpenAPI, and MCP shapes are derived from these normative packages. Component-level metadata (name, version, description, capabilities) is stored in the act:component WASM custom section rather than as a WIT export.

  3. Overview of the ACT (Agent Component Tools) protocol

    ACT is a protocol for packaging tools as WebAssembly (.wasm) components. It allows a single tool artifact to be executed across multiple hosts, including AI agents via Model Context Protocol (MCP) using stdio or HTTP, developers via a CLI, and browsers via a web runtime.

    Key benefits include:

    • Transport Agnostic: One .wasm file works across MCP, CLI, and Browser.
    • Sandboxed Security: Uses a deny-by-default filesystem and network sandbox where capabilities are declared in the component and intersected with host policy.
    • Unified Metadata: Metadata from build files (e.g., Cargo.toml, pyproject.toml) is merged into a signed act:component custom section in the WASM binary.
    • Consistency: Artifacts are pinned by digest and signed, ensuring the same bytes run regardless of the environment.

  4. Understand the Act component security model

    Act uses a policy engine to gate all external capabilities (filesystem, outbound HTTP, raw sockets, credentials, and semantic classes). The effective policy is the intersection of two factors: the operator's grant (provided at runtime via CLI flags, profiles, or config) and the component's ceiling (declared in act.toml under [std.capabilities.*]). An undeclared capability is always denied, regardless of the operator's grant.

  5. Sandbox third-party tools using ACT capability ceilings

    ACT secures third-party tools by layering a 'declaration-as-ceiling' policy model over WASI capability imports and wasmtime VM isolation. The security model consists of four layers: a declared ceiling, runtime policy, DNS-layer deny-CIDR, and per-hop redirect re-checks. This ensures that tools from untrusted authors can be safely executed by an agent.

  6. Use act:core types for cross-cutting data

    The act:core package provides fundamental types used across the protocol, including CBOR byte strings, namespaced metadata, localized strings, and structured errors. Well-known error kinds include std:not-found, std:invalid-args, std:timeout, std:capability-denied, std:internal, and std:session-not-found.
    package act:core@0.4.0;
interface types {
  type cbor = list<u8>;
  type metadata = list<tuple<string, cbor>>;
  variant localized-string {
    plain(string),
    localized(list<tuple<string, string>>),
  }
  record error {
    kind: string,
    message: localized-string,
    metadata: metadata,
  }
}

  7. ACT Architecture and Interface Specifications

    ACT components are based on WebAssembly and export specific interfaces defined in WIT (WebAssembly Interface Type) files. The host reads component metadata from a WASM custom section (act:component in CBOR format) without needing to instantiate the component first.

    Required and Optional Interfaces:

    • tool-provider: Exported by every component to provide tool functionality.
    • act-sessions: Exported by stateful components; used by bridges (like mcp-bridge or openapi-bridge) and components with a session lifecycle.
    • act-core: Provides cross-cutting types used by both the provider and session interfaces.

  8. Understand the ACT component model

    An ACT component is a single .wasm file. All information required for a host to decide whether to run the component is contained within the file in a CBOR-encoded WASM custom section (act:component). This allows for inspection, signing, and distribution without executing the code.

    Each component contains:

    • Tools: Names, descriptions, JSON Schemas, usage hints, and behavioral annotations.
    • Capability Declaration: The classes of host resources the component intends to access.
    • Agent Skill (Optional): Prose instructions for the LLM/model that will invoke the tool.
    act info actpkg.dev/library/sqlite        # Inspects component metadata without executing code

  9. Understand the Component Capability Ceiling

    The 'ceiling' is the set of capabilities a component declares in its manifest.

    • act-build pack validates the manifest at build time.
    • The host re-validates the manifest at load time.
    • If a component attempts an action not declared in its manifest, the host rejects it as outside ceiling, regardless of the user's grant settings.

  10. Define an Agent Skill for a component

    An Agent Skill is markdown documentation designed for an LLM agent that will call a component's tools. It consists of a SKILL.md file with YAML frontmatter and optional supporting files. The skill is bundled into the act:skill WASM custom section during the build process.

  11. Run sandboxed MCP servers with ACT

    ACT provides a secure alternative to running MCP servers as native processes (e.g., via npx or uvx). It packages tools as WebAssembly components with declared capabilities and a deny-by-default policy for filesystem and network access, allowing agents to safely execute tools written by third parties.

  12. Isolate ACT components using Wasm sandboxing

    ACT components run within a wasmtime virtual machine, providing memory safety and instruction-level isolation. This sandbox ensures that components cannot make syscalls unless they are explicitly imported through WASI, eliminating the kernel attack surface typically associated with container escapes.