diff --git a/docs/topics/faq.md b/docs/topics/faq.md new file mode 100644 index 0000000..d330b53 --- /dev/null +++ b/docs/topics/faq.md @@ -0,0 +1,316 @@ +# Frequently Asked Questions + +This page answers questions ACS gets from enterprise security teams, framework implementers, researchers working on agent-security paradigms, and the press. If your question is not answered here, open an issue or join the working group. + +--- + +## About ACS + +### What is ACS? + +ACS (Agent Control Standard) is a runtime governance specification for AI agents. It defines how an agent reports the actions it is about to take, how an external policy engine ("Guardian Agent") responds with a decision, what behavior the agent must exhibit in response, and what audit record the interaction leaves behind. The spec is organized into three pillars: + +``` + ┌──────────────────────────────────┐ ┌──────────────────────────────────┐ ┌──────────────────────────────────┐ + │ Instrument │ │ Trace │ │ Inspect │ + │ Runtime hooks + dispositions │ │ Deterministic event emission │ │ Agent Bill of Materials │ + │ │ │ │ │ │ + │ • 19 lifecycle hooks (steps/*) │ │ • OTel semconv mappings, │ │ • Canonical AgBOM schema │ + │ • 5 dispositions │ │ one per step │ │ • CycloneDX 1.6 serialization │ + │ (allow / deny / modify / │ │ • OCSF event-class mappings, │ │ • SPDX 3.0 serialization │ + │ ask / defer) │ │ one per step │ │ • SWID serialization │ + │ • Two-layer Guardian │ │ • Deployment emits at least │ │ • agbom/snapshot at session start│ + │ • Approver model (ASK) │ │ one of OTel / OCSF │ │ • agbom/changed on every │ + │ • SessionContext + Intent │ │ • Decision-as-span-event rule │ │ mid-session mutation │ + │ • Replay protection │ │ • Provenance carried forward │ │ │ + │ • JSON-RPC 2.0 envelope │ │ onto every emitted event │ │ │ + │ • HMAC-SHA256 baseline signature │ │ │ │ │ + │ • system/ping liveness │ │ │ │ │ + └──────────────────────────────────┘ └──────────────────────────────────┘ └──────────────────────────────────┘ +``` + +The full picture is in [Core Concepts](./core_concepts.md). + +### Why does this need a standard? + +Today, every agent framework logs differently, gates differently, and exposes a different set of interception points. An enterprise running agents across multiple coding assistants, IDE copilots, and runtime frameworks writes a custom integration per framework for one security policy. ACS removes that duplication: a single Guardian, written once against the standard, governs every framework that adopts it. + +### Who needs ACS? + +Three groups, with different motivations: + +- **Enterprise security teams** running multiple AI agents (coding assistants, IDE copilots, internal automations) need one policy that governs all of them. ACS gives them one runtime control envelope — wire contract, Guardian, audit chain, Trace events into the SIEM, AgBOM into supply-chain tooling — that works across every conformant framework, instead of building each piece per framework. +- **Framework and platform builders** need a way to make their security story portable. Adopting ACS means their customers' existing security investments work against the framework on day one, without bespoke integration. +- **Compliance and audit functions** need their agent governance to produce a record an outside auditor will trust — tamper-evident, cryptographically signed, and reconstructible after the fact. The first two groups want to prevent the wrong action in real time; this group needs to *prove* what happened, months later, in a form that survives a regulator's challenge. ACS-Audit (hash-chained audit log committing to request content) plus ACS-Crypto (signed envelopes, post-quantum-ready) produce that record; most off-the-shelf agent platforms cannot. + +This is true even for a single agent on a single framework. ACS adds four concrete things the framework does not provide on its own: actions intercepted before they execute (the framework calls the Guardian and waits before sending the email or making the API call), a hash-chained audit log of every action and decision, a policy authority outside the LLM's context that prompt injection cannot influence, and OTel + OCSF event streams the SIEM consumes without bespoke parsing. + +### What is new here? + +Existing efforts solve one slice each. Vendor governance tools come with each vendor's own policy library and policy language, work only against the frameworks the vendor has integrated, and produce the vendor's own audit format. Research frameworks like FIDES, CaMeL, and IBAC define *enforcement mechanisms* (information flow control, intent-bound authority, capability separation) but not what to enforce and not a wire contract. Observability standards like OpenTelemetry and OCSF record what happened but do not gate what is about to happen. ACS is the contract that lets all of these compose: vendors compete on Guardian quality, paradigms ride on top, observability stacks consume the resulting events. + +### Who is behind ACS? + +ACS is a vendor-neutral community effort led by a group of industry practitioners working across six parallel workstreams. No single company owns or steers the standard; workstream leads come from multiple organizations, and every PR goes through community review. + +| Workstream | Leads | +|---|---| +| Spec and Release | Ariel Fogel, Bar Kaduri | +| Identity | Eva Benn, Richard Bird | +| Testing and Validation | Aruneesh Salhotra | +| Coding Agents | _recruiting_ | +| Ref Impl & Framework Integrations | _recruiting_ | +| Documentation and Content | _recruiting_ | + +Governance is by workstream leads (the Architecture Review Board) with an Advisory Board of executives and SMEs driving adoption. Cadence is a biweekly working-group call. Contribution path is in [CONTRIBUTING.md](https://github.com/Agent-Control-Standard/ACS/blob/main/CONTRIBUTING.md). + +--- + +## Scope and boundaries + +### Is ACS another agent framework? + +No. Agent frameworks and ACS sit at different layers. A framework builds the agent — it gives developers the tools, memory, planning, orchestration, and model choice to construct one. ACS is a **runtime governance specification**: it defines both the wire contract between the framework and a Guardian and the behavior the framework must exhibit (for example, the framework must wait for the Guardian's decision before acting on it). Any agent framework can be ACS-conformant; ACS doesn't compete with frameworks, it's the standard they conform to so an enterprise's security infrastructure can hold the agent accountable. + +### Does ACS replace MCP or A2A? + +No. ACS wraps them. MCP messages flow through `protocols/MCP/*` ACS methods so the same Guardian can govern an MCP tool call as a native tool call. A2A wrapping arrives in v0.2 ([Specification §extend_a2a](../spec/instrument/a2a/extend_a2a.md)). The composition rule: every protocol-spanning message crosses an ACS hook on the way out and on the way back. + +### Does ACS define what policies to enforce? + +No. ACS defines the contract for asking the policy and honoring its answer. The policy itself is the deployment's choice: deterministic rules in OPA/Rego, a Cedar policy bundle, an LLM-backed reasoner under the Agent layer, or any combination. v0.1 leaves the policy language unconstrained and the policy library to the deployment. + +### Is ACS just observability? + +No. ACS evolved out of an earlier initiative called **AOS (Agent Observability Standard)**, which focused only on event emission. As the working group matured, runtime enforcement became the central concern, and the spec expanded to include hooks that fire **before** the action executes, dispositions the agent must honor (`allow`, `deny`, `modify`, `ask`, `defer`), and the runtime behavior that goes with them. The project rebranded to ACS to reflect the broader scope: observability is the Trace pillar; control is the Instrument pillar; inventory is the Inspect pillar. + +### Does ACS prevent prompt injection? + +No, and no runtime mechanism can. Current research finds essentially every production LLM remains vulnerable to some form of prompt injection. What ACS prevents is the agent acting on injected reasoning without being detected. + +The mechanism is **deviation detection**. ACS requires the agent to declare what it is doing this session (its intent) and to send each proposed action through a Guardian before executing it. The Guardian compares the action against three things: the declared intent, the policy library, and the trust basis of the data driving the action. An injected agent generally deviates on at least one of those three, and the Guardian denies, modifies, or escalates the action before it runs. + +Injection still happens. The LLM's reasoning still gets corrupted by attacker-controlled input. But the action it would have taken becomes visible, gated, and auditable, which is a strictly stronger property than asking the model to ignore attacker instructions in the first place. + +--- + +## For framework implementers + +### How do I make my framework ACS-conformant? + +Implement **ACS-Core**, which has ten components: + +1. **Handshake** — `handshake/hello` with ClientHello and ServerHello capability negotiation +2. **JSON-RPC 2.0 envelope** — with `request_id`, `timestamp`, `acs_version`, and `metadata` required on every request +3. **Hook taxonomy minimum** — `sessionStart`, `userMessage` or `agentTrigger`, `toolCallRequest`, `toolCallResult`, `agentResponse`, `sessionEnd` +4. **Five dispositions** — `allow`, `deny`, `modify`, `ask`, `defer` with the required fields per disposition +5. **SessionContext** — `session_id`, rolling `chain_hash` (SHA-256), append-only ContextEntry chain, with the Guardian publishing the chain head on content-bearing responses. Intent is optional in core but required for IBAC deployments. +6. **Replay protection** — `request_id` (UUID) and `timestamp` on every request; Guardian MUST reject replays per §10.3 +7. **Baseline integrity** — HMAC-SHA256 signature over the canonical envelope on every request and response, with an HKDF-derived per-session key +8. **Decision honoring** — the Observed Agent MUST wait for the Guardian's decision and apply it; on decision failure (timeout, transport failure, error response) it applies the `on_decision_failure` posture (default `proceed`, fail-open) and records every fail-open proceed as an audit event (§6.4) +9. **Liveness** — `system/ping` +10. **Wrapped MCP** — `protocols/MCP/*` for governing MCP tool calls under the same Guardian + +Additional hooks (`turnStart`/`turnEnd`, `preCompact`/`postCompact`, `subagentStart`/`subagentStop`, `knowledgeRetrieval`, `memoryContextRetrieval`, `memoryStore`, `skillRegister`/`skillLoad`/`skillUnload`) are normatively defined and SHOULD be implemented when the framework can observe the corresponding event. The handshake declares which methods the framework implements and the Guardian negotiates accordingly. + +ACS-Core does NOT require field-level Provenance, Trace event emission, AgBOM, asymmetric or post-quantum signatures, or `request_hash` on ContextEntry. Those are organized as optional profiles deployments can layer on. See [Conformance Profiles](../spec/conformance.md). + +``` + ┌────────────────────────┐ + │ ACS-Core (mandatory) │ + └────────────────────────┘ + │ + ┌─────────────┬─────────────┼─────────────┬─────────────┐ + │ │ │ │ │ + ▼ ▼ ▼ ▼ ▼ + ┌─────────┐ ┌─────────┐ ┌─────────────┐ ┌──────────┐ ┌──────────┐ + │acs-trace│ │acs- │ │ acs- │ │acs-crypto│ │acs-audit │ + │ │ │inspect │ │ provenance │ │ │ │ │ + └─────────┘ └────┬────┘ └─────────────┘ └──────────┘ └──────────┘ + │ + ▼ + ┌──────────────────┐ + │ acs-inspect- │ + │ dynamic │ + └──────────────────┘ +``` + +Profiles compose: a minimal IDE harness declares `["acs-core"]`; a full-coverage enterprise deployment declares all seven. The handshake makes the choice explicit and the Guardian negotiates accordingly. + +### What if my framework does not have a particular hook surface? + +If the framework cannot observe the event a hook is meant to gate, the framework does not advertise that hook in `methods_implemented` at handshake time. The Guardian's `methods_evaluated` response names the subset it will actually evaluate against policy, and the Guardian may refuse the session if a hook its policy requires is absent. So the negotiation is explicit on both sides — the framework says what it can emit, the Guardian says what it needs to see, and they either agree to proceed or the session does not start. + +The conformance line is between *not having the surface* and *suppressing the hook for an event that did happen*. The first is fine and negotiated explicitly. The second is non-conformant: a framework that observed the event and skipped the hook is in violation, regardless of which surrounding hooks it did fire. + +### Does ACS require a specific transport, cryptography, or identity system? + +No, same principle for all three: ACS specifies the category (you need a transport, you need signed envelopes, you need an identity scheme) and catalogs the options the spec defines; the deployment picks which. + +- **Transport.** v0.1 defines HTTP(S) (for SaaS, on-prem, multi-tenant Guardians) and stdio (for IDE-embedded Guardians); gRPC and unix sockets are deferred to v0.2. The handshake declares which is in use, and the envelope and method semantics are transport-agnostic. +- **Cryptography.** ACS-Core's baseline is HMAC-SHA256, which any deployment can satisfy without infrastructure investment. ACS-Crypto adds asymmetric and post-quantum algorithms (ML-DSA-65 primary, SLH-DSA-128s backup, hybrid composites for transitional deployments) for deployments that need non-repudiation or PQC readiness. +- **Identity.** SPIFFE, OIDC, mTLS, and organizational PKI are all deployment choices; ACS reserves `policy_references[].policy_version` as a stable pointer so audit replay works regardless of the scheme. + +**ACS catalogs what exists; the deployment picks what to use.** + +### Where is the schema? + +JSON Schemas for every envelope and hook payload are under [`specification/v0.1.0/`](https://github.com/Agent-Control-Standard/ACS/tree/main/specification/v0.1.0). Data-bearing hooks ship two variants: the base schema (permissive, where `provenance` is optional) and the `*.acs-provenance.json` strict variant required by the ACS-Provenance profile. + +--- + +## For enterprises + +### How do I deploy ACS? + +Four steps: + +1. **Pick or build a Guardian.** Options: in-house implementation, vendor product, or open-source reference implementation. +2. **Deploy the Guardian in your security perimeter** — the same place you put other policy enforcement infrastructure (VPC, behind your auth boundary). +3. **Configure each agent platform to point its hook surface at the Guardian** — over HTTP(S) for SaaS, on-prem, and multi-tenant deployments; over stdio for IDE-embedded ones. +4. **Populate the Guardian's policy library and declare your profiles in the handshake** — `acs-core` is mandatory; add `acs-trace`, `acs-inspect`, `acs-provenance`, `acs-crypto`, and `acs-audit` as your deployment needs. + +### Does ACS work in IDE, SaaS, and on-prem deployments? + +Yes. The IDE case (coding assistants and IDE copilots) uses stdio transport with implicit process-spawn authentication. The SaaS case uses HTTP(S) with mTLS or bearer tokens. The on-prem case can use either, depending on whether the Guardian is in the same process tree or accessed over the network. The handshake negotiates which transport, which auth, and which profiles apply. + +### What is the operational overhead? + +Depends on the implementation. In well-tuned deployments the overhead is below the noise floor of the LLM inference call itself — close to imperceptible. + +Each gated action is one Guardian round-trip. With a deterministic Guardian (Cedar / OPA / Rego) running locally or in a co-located service, per-action latency is microseconds to single-digit milliseconds. Hooks fire on actions that cross out into the real world (tool calls, memory writes, external messages), so the round-trip count is proportional to action volume rather than token volume. For a typical agent that takes 5 to 10 such actions per session, total Guardian overhead lands in the tens-of-milliseconds range while inference itself remains the dominant cost. + +A deployment that adds the LLM-backed Guardian layer for some escalations pays per-escalation inference cost on top of that, which is the deployment's tuning knob. + +### What happens when the Guardian fails? + +The default is fail-open with mandatory audit: if the Guardian times out, the transport fails, or the Guardian returns an error, the action proceeds and the bypass is recorded as an audit event. Deployments that prefer fail-closed flip one field in the handshake (`on_decision_failure: deny`). One subtlety: when the Guardian responds with DEFER and the resolution itself times out, that fails closed by default. Silence fails open; expressed-but-unresolved concerns fail closed. See [Specification §6.4](../spec/instrument/specification.md#64-honoring-decisions-normative). + +``` + ┌────────────────┐ + │ Hook submitted │ + └────────────────┘ + │ + ▼ + ┌────────────────┐ + │ Guardian │ + └────────────────┘ + │ │ + responds │ │ no response in time + in time │ │ (timeout / error / silence) + ▼ ▼ + ┌──────────────────┐ ┌──────────────────────────────┐ + │ Apply decision │ │ Decision failure │ + │ │ │ │ + │ allow / deny / │ │ default: proceed │ + │ modify / ask / │ │ + audit event │ + │ defer │ │ │ + │ │ │ opt-in: deny (blocked) │ + └──────────────────┘ └──────────────────────────────┘ +``` + +### Does ACS handle multi-tenancy? + +The wire reserves an optional `tenant_id` field in v0.1. Detailed multi-tenant isolation (per-tenant policy scoping, SessionContext isolation, cross-tenant A2A rules) is deferred to v0.2 when SaaS Guardian providers need it. The v0.1 commitment is the field, so deployments adopting ACS today do not face a breaking-change migration when isolation rules ship. + +### How does ACS integrate with my existing security stack? + +Through the Trace pillar. ACS-Trace requires every step to emit at least one of an OpenTelemetry span or an OCSF event with the required attributes. So any SIEM or observability back-end that accepts OpenTelemetry or OCSF consumes ACS events the same way it consumes anything else. The Inspect pillar emits an Agent Bill of Materials in CycloneDX, SPDX, or SWID, which feeds standard SBOM and supply-chain tooling. + +### How does ACS map to OWASP Top 10, NIST AI RMF, and the EU AI Act? + +ACS exposes control points and audit surface; the deployment's policy library decides what gets caught. The mapping is mechanism-to-control, not promise-to-eliminate. + +**OWASP Agentic Top 10 (2026):** + +| OWASP risk | ACS mechanism | +|---|---| +| ASI01 Cognitive injection | Hook surface intercepts the action the injected reasoning produces; the Guardian sits outside the LLM context | +| ASI02 Over-broad skill manifests | `skillRegister` exposes `declared_capabilities`; Guardian compares against the capabilities the composed tools actually expose | +| ASI04 Compositional skill payloads (SkillTrojan) | `skillRegister` exposes the whole skill definition for compositional static analysis before any action runs | +| ASI06 Tampered skill artifacts (BADSKILL) | `definition.digest` commits to the complete loadable artifact including bundled model weights; `registration_provenance` attests origin | +| ASI08 Load-time activation | `skillLoad` correlates to an approved `skillRegister` by `(skill_id, digest)`; uncorrelated or digest-mismatched loads are denied | +| ASI10 Load/unload churn evasion | `skillUnload` plus AgBOM inventory keep churn auditable | +| Memory poisoning | `memoryStore` and `memoryContextRetrieval` hooks; provenance travels with stored content so retrieval recovers the original trust basis | +| Excessive agency / capability scope | SessionContext + Intent with IBAC-style enforcement; `Intent.parsed` immutable to the runtime LLM | +| Confused deputy / cross-agent propagation | `protocols/A2A/*` wrapping (v0.2); `subagentStart`/`subagentStop` govern in-process subagents | + +**NIST AI RMF:** the framework requires identification, measurement, and management of AI risks, with traceability and human-control obligations. ACS contributes the runtime traceability layer — ACS-Audit's hash-chained record, ACS-Inspect's AgBOM, ACS-Trace's events — and the ASK disposition gives human oversight as a wire-level primitive. + +**EU AI Act (high-risk AI systems):** requires logging that allows post-hoc reconstruction, transparency obligations, and human oversight. ACS-Audit's `request_hash`-committing chain produces a tamper-evident reconstruction surface; ACS-Inspect's AgBOM identifies the components, models, and data sources used; ACS-Crypto's signed envelopes give non-repudiation. DEFER and ASK dispositions give human-oversight checkpoints expressible at the wire level. + +A deployment claiming `acs-core` + `acs-provenance` + `acs-inspect` + `acs-audit` + `acs-crypto` covers the bulk of the surface across all three frameworks at the protocol level. Whether the coverage catches a specific attack or satisfies a specific auditor depends on the policy library and the deployment's procedures. + +--- + +## For researchers and paradigm authors + +### Does ACS support FIDES, CaMeL, IBAC, or AARM? + +Yes, all four, on the same wire contract. ACS is paradigm-neutral on the contract and lets paradigm-specific intent ride on existing fields (`policy_data`, `reason_codes`, `cited_provenance_ids`, `policy_references`). + +``` + ┌─────────┐ ┌──────────────────────────────────┐ + │ FIDES │ ───► label joins from lineage ───────────► │ ACS-Provenance │ + │ │ │ + cited_provenance_ids │ + └─────────┘ └──────────────────────────────────┘ + ┌─────────┐ ┌──────────────────────────────────┐ + │ CaMeL │ ───► per-argument dependency graph ──────► │ Per-arg provenance │ + │ │ │ + cited_provenance_ids │ + └─────────┘ └──────────────────────────────────┘ + ┌─────────┐ ┌──────────────────────────────────┐ + │ IBAC │ ───► authority bound at intent commit ───► │ SessionContext + Intent │ + │ │ │ + ASK + dispositions │ + └─────────┘ └──────────────────────────────────┘ + ┌─────────┐ ┌──────────────────────────────────┐ + │ AARM │ ───► interception + tamper-evident ──►│ Dispositions │ + │ │ receipts │ + ACS-Audit chain │ + └─────────┘ └──────────────────────────────────┘ +``` + +How each paradigm composes with ACS: + +- **FIDES** — uses ACS-Provenance lineage from each hook payload to run its integrity / confidentiality label arithmetic. ACS carries the `origin`, `source_id`, and `derived_from` facts; the FIDES Guardian computes the label joins and decides what the planner sees. +- **CaMeL** — uses per-argument provenance to reconstruct the data-flow dependency graph, then applies its capability calculus against tool calls. ACS carries the dependency facts; the CaMeL Guardian runs the policy against them. +- **IBAC** — uses SessionContext + Intent for authority binding, the ASK disposition for approver-driven extensions, and the authorize-before-action flow for enforcement. ACS carries the wire fields and enforces `Intent.parsed` immutability; the IBAC Guardian provides the intent parser, capability-matching logic, and approver UX. +- **AARM** — maps to ACS-Core almost directly. AARM-style deployments declare ACS-Audit for the tamper-evident receipt chain and adopt AARM's receipt conventions on top. + +The pattern across all four: ACS contributes the wire format and runtime behavior; the paradigm contributes the policy substance. Together they make the paradigm portable across any conformant framework. + +### How is ACS different from those research artifacts? + +The papers define enforcement *mechanisms* (label-based information flow, intent-bound authority, capability separation, interception with receipts) and prove what guarantees those mechanisms give. They do not define what to enforce (still the deployment's policy library), and they do not ship a wire contract a security team can deploy against frameworks they do not control. ACS sits at a different layer: the mechanism stays the paradigm's; the wire format and runtime behavior that let the mechanism cross frameworks is ACS's. + +Beyond that layer difference, ACS specifies five things none of AARM, FIDES, CaMeL, IBAC, or Conseca specifies: + +1. **A complete wire envelope** — JSON-RPC 2.0 with required fields, disposition vocabulary (allow / deny / modify / ask / defer), replay protection, baseline HMAC-SHA256 integrity. The actual bytes a framework emits. +2. **A concrete hook taxonomy** — 22 named hooks across `steps/*`, `agbom/*`, and `system/*`, each with a JSON schema and a fixed firing context. The research frameworks describe abstract control points (`intent.parse`, `action.authorize`, `context.ingest`); ACS defines them as concrete wire methods with payloads. +3. **Three-pillar coverage in one spec** — Instrument (runtime control), Trace (observability), Inspect (inventory). Each research framework addresses one slice. +4. **Conformance profiles** — declarable tiers (`acs-core`, `acs-trace`, `acs-inspect`, `acs-provenance`, `acs-crypto`, `acs-audit`) letting deployments mix capabilities and Guardians negotiate compatibility at handshake time. +5. **Runtime behavior contract** — the agent waits for the Guardian's decision, honors the disposition, records fail-open proceeds. AARM describes the architecture; ACS specifies the conformance behavior. + +The composition story is the practical payoff: one Guardian can run FIDES, IBAC, and AARM-style enforcement against the same hook payloads at the same time, because the wire stays paradigm-neutral. + +### Where do I plug in a new paradigm? + +ACS is intentionally extensible without wire surgery. A new paradigm names itself a key in `policy_data` (conventionally lowercase, e.g. `"my-paradigm": { ... }`), defines its `reason_codes` vocabulary, optionally proposes a conformance profile if it needs a declarable capability tier, and writes a binding to one of the reference policy engines (OPA/Rego is the v0.1 reference). The wire contract stays neutral. See [Spec Review Principle 4](https://github.com/Agent-Control-Standard/ACS/blob/main/SPEC_REVIEW_PRINCIPLES.md#4-the-wire-is-paradigm-neutral-new-paradigms-ride-existing-elements-first). + +### Will ACS adopt my paradigm into the core spec? + +When a paradigm needs a wire signal that no existing field can carry, yes. That is the bar for promoting something from `policy_data` into a top-level field. Field-level Provenance was promoted because trust-laundering across summaries and memory writes is unrecoverable from logs (Spec Review Principle 3). Most paradigms do not cross that bar and ride existing elements indefinitely, which is the intended behavior. + +--- + +## Versioning and roadmap + +### What is in v0.1.0? + +ACS-Core (mandatory), and six optional profiles: ACS-Trace, ACS-Inspect, ACS-Inspect-Dynamic, ACS-Provenance, ACS-Crypto, ACS-Audit. Full content lock and the design record are in [Conformance Profiles](../spec/conformance.md) and the [v0.1.0 schemas](https://github.com/Agent-Control-Standard/ACS/tree/main/specification/v0.1.0). + +### What is coming in v0.2? + +A2A wrapping (the `protocols/A2A/*` namespace is reserved in v0.1), the sensitivity / timeout model with method/capability mapping rules, multi-tenant isolation rules, batching and streaming hook semantics, and a Policy Attestation profile that binds policy references to verifiable author signatures. Conformance test machinery and a public registry are also v0.2 work. + +### How do I follow or contribute? + +The repo is [Agent-Control-Standard/ACS](https://github.com/Agent-Control-Standard/ACS). Working-group calls and contribution guidance are in [CONTRIBUTING.md](https://github.com/Agent-Control-Standard/ACS/blob/main/CONTRIBUTING.md). Issues are open across all three pillars. diff --git a/mkdocs.yml b/mkdocs.yml index 1478734..073eda3 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -66,6 +66,7 @@ nav: - Topics: - Core concepts: topics/core_concepts.md - ACS in Action: topics/ACS_in_action_example.md + - FAQ: topics/faq.md - Concepts: - Overview: concepts/README.md - Agents: concepts/agents.md