Proposal: host-side AffixIO attestation alongside ADR observe/detect/prevent

Open
  • Is something wrong?
#128 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
python
Domain
security

Research direction

Start by reading the README sections on Prevention and the Sensor schema; the issue does not identify specific files or tests. The first step is to get maintainer direction on whether this belongs in documentation, a Sensor schema change, or a local example, and whether to wait for Prevention OSS. Done would require an agreed scope and a minimal contribution matching it.

Written by the indexing model from the issue text.

Description

Summary

AffixIO can sit next to ADR as complementary host-side signed ACTION yes/no proof for consequential agent tool calls. ADR already observes activity, detects threats, and (in product) prevents unsafe actions. AffixIO would not replace that loop. It would add signed allow/deny evidence ADR can cite in detection/response, and optionally gate unsafe tool calls with host proof before execution.

Happy to stop at discussion, or contribute a minimal example if maintainers want one.

Why this fits

ADR Discovery/Sensor/Detection already cover inventory, telemetry, and threat detection. Prevention is called out in the README but is not in the current open-source release. Host-side attestation is a natural companion:

  • ADR sees what the agent did or tried to do.
  • AffixIO signs a concrete ACTION allow/deny decision on the host.
  • Detection/response can treat that signature as citeable evidence, not another opaque policy black box.

Scope lock for AffixIO here: PII stays on the host. This is not person/age/KYC identity.

Product surface (AffixIO)

Proposed sit (no full wrap)

Optional complementary path only:

  1. Before a consequential tool call executes, request AffixIO host attestation for that ACTION.
  2. If denied, do not execute; emit signed deny evidence into the ADR observability/detection trail.
  3. If allowed, proceed and attach signed allow evidence so ADR Detection can cite it later.

This stays outside ADR core. No proposal to vendor AffixIO into Discovery/Sensor/Detection, and no full SDK wrap of ADR.

Ask for maintainers

  1. Does complementary host-side attestation belong in ADR's open-source direction (docs/example note, Sensor schema field for attestations, or wait until Prevention OSS lands)?
  2. If useful, would you prefer a short docs note plus a minimal local example under something like Sensor/examples/, or hold until Prevention is public?
  3. Any schema constraints for attaching signed evidence to Sensor events without bloating the unified telemetry model?

If maintainers want a minimal example, AffixIO can provide a small FIT-for-PR sketch (local stdio MCP + signed ACTION gate stub) and stop there. No large wrap planned.

Dominant language
Python
Stars
2.1k
Forks
231
Avg merge
16h 8m
Merged PRs (30d)
2

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from uber/ADR

All issues in uber/ADR

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.