feat: govern accumulated context across delegated agent workflows

[Knapp-Kevin]

Summary

AGT evaluates actions one at a time today. The catch is that a multi-agent workflow can pass every individual policy check and still end up somewhere it shouldn't, because sensitivity builds up as context accumulates across steps. A delegated agent can also quietly lose the constraints its parent was working under. I'd like to propose tracking the accumulated context of a workflow and checking actions and delegations against that running state, instead of only looking at the request in front of us.

The problem

AGT already governs actions, tools, identity, policy decisions, and audit events, but it mostly treats them as separate events. There's a gap when:

• A series of individually fine actions adds up to sensitive context.
• A derived result (an inference) ends up more sensitive than any of the inputs it came from.
• A delegated agent inherits workflow state that the current authorization decision doesn't actually see.

Concrete example: a customer's name, their renewal status, some usage analytics, and a couple of financial indicators are each low to moderate sensitivity on their own. Put them together and you can derive a fairly sensitive customer risk profile (churn likelihood, financial distress, account vulnerability). The policy engine approves each step while the combined picture quietly crosses a line.

The question I'd like governance to be able to ask before allowing an action or a delegation is basically: what will this agent be able to know or do once this action succeeds?

Why it fits the toolkit

This doesn't need a parallel stack. It composes with things AGT already has:

• DataClassification, DataLabel, and ABACPolicy in agent_os/policies/data_classification.py already give us a sensitivity ladder and a label vocabulary to reuse.
• The Rust policy engine already attaches result_labels to a verdict and carries them from one call to the next (policy-engine/core/src/verdict.rs). The accumulated envelope is really just the durable, workflow-scoped version of that.
• DelegationChain in the structural-authz integration already attenuates scopes on delegation. I'd extend it with restriction inheritance rather than replace it.

What I'm proposing (first cut, in-process)

A ContextEnvelope: an immutable, versioned value holding the labels accumulated so far, an aggregate sensitivity (the max over DataClassification), and a grow-only set of restrictions. On top of that:

• Aggregation rules over label combinations, with a backstop so combinations nobody wrote a rule for escalate for review instead of slipping through. Growing the label set by itself shouldn't elevate anything; only declared combinations should.
• Accumulate after execution, not before. Fold in an action's actual result_labels once it has run, then check the next action against the updated state. I looked at projecting the envelope before running the action and decided against it, since you can't really gate on the labels of an output you haven't produced yet.
• A constrain outcome that means "allow, but carry these obligations forward." On the declarative policy path, which has no way to carry obligations, it fails closed to deny rather than quietly allowing.
• Restriction inheritance on delegation: a child's restrictions are the parent's plus whatever the child adds. A delegatee can add restrictions but never drop one. This sits alongside the existing scope attenuation and doesn't touch validate().
• CONTEXT_* audit events for the transitions, each classified at least as high as the envelope it describes.

How I'd know it works

• Folding is order independent and idempotent; sensitivity only ever goes up; restrictions never get dropped.
• A rule over [pii, financial] elevates to restricted; an unenumerated multi-category combination escalates; adding an unrelated label doesn't change the classification.
• A restriction that's present gates its action regardless of sensitivity, so there's no quietly allowing it below some threshold; a constrain with nowhere to carry obligations becomes a deny.
• A delegated child can't end up with fewer restrictions than its parent.
• The existing DelegationChain tests stay green and validate() behaves exactly as before.
• No new dependencies.

What I'm leaving out for now

These are real and probably deserve their own issues, but they're not in this first cut, and anyone deploying should know they're open:

• Splitting work across sibling agents, sessions, or separate workflows so no single envelope ever sees all the labels. Catching that needs a per-principal accumulation register.
• Signing and versioning envelopes that cross a trust boundary between agents. Until that exists, anything riding on an envelope across the mesh is advisory, since a peer could present a weaker one.
• Laundering through an unlabeled store (write it out, read it back clean) or by paraphrasing restricted content into new text. That needs labeling on ingest and taint-style propagation.
• Detecting an undeclared sensitive inference. That's undecidable in general, so for now an artifact produced while the envelope is already sensitive just inherits that classification.

Standards it lines up with

It's mostly a data-governance and access-control control, and worth noting, it stores labels and classification levels rather than the underlying data, which keeps its own footprint small. It lines up with EU AI Act Article 12 (record-keeping) and Article 14 (human oversight), NIST 800-53 around information flow and security attributes (AC-4, AC-16, AC-21), the NIST AI RMF functions, SOC 2 CC6 and CC7, GDPR Article 25, and HIPAA's access and audit controls. There's an existing EU AI Act checklist under docs/compliance that this connects to.

Open questions

• Where should the envelope schema live, and which component owns propagation across the mesh?
• Immutable and versioned, or mutable with audit transitions? I lean immutable.
• Who's allowed to authorize a declassification?
• Should envelope IDs show up in the agt-evidence receipts?

I've written up the full threat model, the invariants, and the diagrams in an ADR and can attach it or open it as a follow-up.

[github-actions]

🔴 Contributor Check: HIGH

Check	Result
Profile	HIGH
Credential	NONE
Overall	HIGH

Automated check by AGT Contributor Check.

[Knapp-Kevin]

Full design writeup is over in the discussions, with the model, the invariants, the threat model, and the diagrams: #2798

[lawcontinue]

Read through discussions/2798. Solid info-flow label reuse and authority intersection model.

Thing I couldn't find: multi-day workflows. Each step produces an immutable envelope version, and the accumulated chain is itself a sensitive artifact (as the risks section notes). Invariant 0 (signing, monotonic versioning) is deferred, which is a bit of a catch-22 — the chain is simultaneously your best audit trail and your softest target.

Without decay or pruning semantics the retention pressure goes both ways: keep forever → envelope store becomes a target; prune → you lose the trail that explains why a restriction exists. Not saying this ships in v1, but the design might want to leave a hook for it.

Have you considered envelope lifecycle semantics — whether decay, minimization, or pruned children can still satisfy the ratchet-up invariant?

[Knapp-Kevin]

This is a good thing to surface early, and I don't think it has a settled answer yet. A direction that might work: treat the ratchet as a property of the current head rather than the whole chain. Within a monotone run the latest version already carries the joined state, so in principle you could compact the intermediate versions without changing what gets enforced, and keep the full trail as an audit choice rather than a correctness requirement.

Where I'm less sure is the edges. Compaction across a declassification looks like it would resurrect what the downgrade removed, so declassifications might need to act as boundaries. And signing a checkpoint proves who attested it but not that the summary is faithful, so there's an open question about whether a checkpoint needs a verifiable summary of what it folds rather than just a signature. I'd also want to nail down the minimum that has to survive pruning, probably the active restrictions plus some reason anchor, but I'm not certain that's enough.

So I'd lean toward leaving this as an open lifecycle and retention question rather than committing to a shape, though I think you're right that the schema should leave room for a checkpoint or compaction record instead of assuming an unbounded chain. Have you seen a retention model that handles the declassification-boundary case cleanly?

[Knapp-Kevin]

Quick follow-up @lawcontinue — the lifecycle question you raised is now captured in the PR as an explicit, documented extension point rather than something v1 tries to settle. The CAG security-audit doc now states the chain is not assumed unbounded, the ratchet is a property of the head (so intermediate versions are compactable without changing what gets enforced), declassification steps act as compaction boundaries, the minimum that must survive pruning is the active restrictions plus a reason anchor, and a checkpoint needs a verifiable summary of what it folds rather than just a signature. No compaction or signing machinery is implemented yet; it stays the named follow-up.

The companion piece from #2798 also landed: an envelope_reference projection that hands a receipt only the opaque envelope id and the coarse sensitivity tier, never the envelope contents.

Both are in #2800. Still curious whether you've seen a retention model that handles the declassification-boundary case cleanly.

[lawcontinue]

Hit this exact problem in our agent governance work — started with full envelope history and ran into unbounded growth during multi-hour delegation chains.

What worked: decouple compaction from declassification. Three-level decay: full → skeleton (constraints + provenance hash + expiry) → shadow (constraint_id + reason_hash). Declassification at L0→L1, pruning at L1→L2. Every transition is signed with Ed25519 over (from, to, content_hash, ts) — signing state transitions, not snapshots.

One thing that bit us: active_restrictions without expires_at + delegated_by means post-prune agents can't tell if a constraint is still in effect. Slapping expiry on the skeleton level fixed it.

[arian-gogani]

The accumulated context problem is exactly where the hash chain structure helps. If every step in the delegation chain produces a signed receipt that references the previous step's receipt hash, the accumulated state IS the chain — and any deviation from the expected accumulation breaks the chain at exactly that point.

Concretely:

Step 1: orchestrator delegates to agent A
  → receipt_1 = sign({action_type: "delegate", scope: "agent-A", policy: "policy-v3"})
  → action_ref_1 = SHA-256(JCS(preimage_1))

Step 2: agent A calls tool X
  → receipt_2 = sign({action_type: "tool_call", scope: "X", chain_hash: hash(receipt_1)})
  → The chain_hash binds step 2 to step 1. If the delegation constraints changed between steps, the binding is broken.

Step 3: agent A re-delegates to agent B
  → receipt_3 = sign({action_type: "delegate", scope: "agent-B", parent_chain: action_ref_1, chain_hash: hash(receipt_2)})
  → Any constraints that were silently dropped between step 1 and step 3 are now auditable from the chain.

This gives you what AGT's current per-action checks miss: proof that the accumulated context (policy constraints, identity, delegation depth) stayed consistent across the full chain — not just at each individual step.

The chain_hash field creates a tamper-evident linkage across steps. An auditor can reconstruct the full delegation chain from any receipt, walking backwards through chain_hash references, without replaying the orchestrator's logs.

pip install nobulex ships this chain structure (Ed25519, JCS/RFC 8785, hash chain). The delegation provenance model described here is directly compatible. Happy to sketch a concrete integration with AGT's policy evaluation layer if useful.

[AgentGymLeader]

Most of the thread is about the after-the-fact side: chain the signed receipts so you can reconstruct the accumulated state later (the hash-chain comments). Useful, but I think that's a different question than the one in the issue.

The issue asks "what will this agent be able to know or do once this action succeeds?" You can ask that before dispatch. The envelope answers it after execution instead, and the reason given (you can't gate on labels of an output you haven't produced yet) is true for the output's sensitivity but not its scope. What an agent will be able to reach — tools, data, other agents — is already fixed before you run anything, whatever label the output ends up with. So there's a second checkpoint that doesn't have the "output doesn't exist yet" problem.

The delegation case is where it bites. The ratchet covers what flows down: restrictions only grow. But what the child starts with is a separate question. Does it inherit the parent's full capability set and then subtract restrictions, or start from a smaller set it never had? To an auditor those aren't the same — "was blocked from X" vs "never had X" — and the second is checkable without replaying the run. Worth knowing which one the envelope actually claims, since the open questions (who authorizes a declassification, whether envelope IDs end up in receipts) read differently depending on the answer.

Same thing on the retention point @lawcontinue raised. If what you enforce is a before-dispatch decision rather than the label chain, re-checking it only needs that decision plus what it evaluated, not the whole history. That takes pressure off the unbounded-growth problem. Keep the full trail for audit if you want, just don't depend on it for correctness.

Not a replacement for the accumulation model. The chain tells you the run stayed consistent; a before-dispatch check tells you what the agent could reach to begin with. Probably want both.

[lawcontinue]

Good distinction — the boundary vs accumulation split is not just complementary, it is different trust assumptions at different cost points.

A few observations on the gap between them:

Boundary trusts the dispatch logic. Chain trusts nothing at runtime. The pre-dispatch invariant "was never in a position to do X" is checkable offline from the delegation config — but it assumes the dispatch logic correctly enumerated the child's reachable scope. In LLM agent scenarios, this is not always a closed-form decision: the child's effective information access depends on what context the parent injects into the prompt, which may itself be a function of outputs not yet produced. So the boundary's decidability has an edge case exactly where delegation meets dynamic prompt construction.

The legal burden differs. "Was never in a position to do X" is a stronger technical invariant, but "was restricted from X" is easier to document as a compliance artifact — you have the policy document that says "denied," and the receipt that shows the deny-set grew monotonically. Under EU AI Act Article 12, the regulator asks "did you take appropriate measures," not "was it theoretically impossible." Both invariants satisfy this, but the restriction-inheritance model produces more directly usable audit evidence.

Retention cost is the practical differentiator. If correctness depends on the boundary decision only, retention is bounded — one record per delegation edge, not one per action. At scale across multi-agent chains, this is a meaningful storage and retrieval cost difference, especially with multi-year retention requirements.

One question worth pinning down: in the current envelope proposal, when a declassification happens mid-chain, which invariant is the auditor actually verifying — the boundary's "never could" or the chain's "stayed within"? The answer changes what you need to retain and what a challenge to the declassification would need to disprove.