active-rpc 2.0.0

Active RPC — capability-based, promise-pipelined, multi-lane RPC for Active Infinity payloads and multi-agent systems
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

# Security policy — Active RPC

## Supported versions

| Version | Security fixes |
|---|---|
| 1.0.x | yes |

## Reporting a vulnerability

Report privately to the `Active-Official` organization (or a GitHub private
security advisory on `Active-Official/active-rpc`). Never include a live
capability id or secret material in a report; describe the shape instead.

Please include:

- the transport and the sequence of envelopes that reproduces the issue;
- the code observed (e.g. `rpc/unknown-capability`) and the expected behaviour;
- the class: forgery, escalation, confused deputy, budget bypass, secret leak,
  malformed-frame acceptance, or a crash/hang.

## Response

- Acknowledgement within 3 business days.
- A fix or mitigation plan within 30 days for a confirmed issue.
- A CVE and patched release for anything affecting a released version.
- Credit in the advisory unless you ask otherwise.

## Scope

In scope: capability minting, attenuation, revocation and lifetime; promise
settlement and pipelining; budget accounting; lane and channel isolation; the
envelope codec and capability table; every transport adapter; tool policies.

Out of scope: the security of a provider's own logic (a provider runs in the
agent's process), network authentication (QUIC uses a self-signed certificate on
loopback; deployments terminate their own TLS), and confidentiality of a
capability id at rest (it is a bearer token).

## Hardening expectations

- The registry is the authority: a wire descriptor never grants anything.
- Attenuation is monotone; any widening is `rpc/attenuation-escalation`.
- Budget is charged per call and intersects capability with lane.
- Secret material is represented by `Value::Secret`, never by bytes.
- Every frame is bounded and rejected at the boundary.
- `#![forbid(unsafe_code)]`.

## What is tested, fuzzed, reviewed, and proven

| Level | What it covers | Where the evidence lives |
|---|---|---|
| **Tested** | kernel, capability lifecycle, attenuation, revocation, promises, lanes, channels, tools, transports, the red-team battery, negative controls and performance budgets | `tests/`, `docs/hardening/STATUS.md` |
| **Fuzzed** | nine structure-aware targets: envelope, capability lifecycle, promise graph, budget matrix, MCP/HTTP/process tools, channel transfers, transport framing | `fuzz/`, committed corpora, nightly 200k-run campaign |
| **Reviewed** | independent review rounds with triaged findings and regression tests for every fix | `REVIEWS.md`, `docs/hardening/REVIEW-SCOPE.md` |
| **Proven** | monotone attenuation, revoke-at-dispatch and single settlement are stated as invariants and property/model-tested; they are **not** machine-checked proofs | `docs/spec/security.md` |

Nothing in this crate is formally verified. The claims are bounded by the
checked-in tests and the documented residual risks; a property that is not in
that table is not claimed.