Aggrete

The open-source proxy. Product site: https://aggrete.com. This repo is the proxy and nothing else: engine, accumulator, ingest CLI, Helm chart.

An MCP proxy that enforces a code of conduct document across connectors, with state that accumulates per user.

Every MCP gateway on the market authorizes tool calls and logs them. None of them answer the question that actually matters once an assistant can reach Glean, Salesforce, Slack and Drive at once: is this call, combined with everything this person has already pulled today, something the code of conduct forbids?

Four individually-authorized questions can assemble a layoff list. No guardrail fires, because no single question was sensitive. This proxy is the missing layer.

Install

pip install aggrete            # published on PyPI
# or with uv:
uv tool install aggrete        # installs the aggrete CLI
uvx aggrete --demo             # or run it without installing

aggrete --config proxy.config.yaml

Or clone this repo to get the demo, sample policy and Helm chart.

What the proxy does

• Try it in one command: aggrete --demo (or docker run --rm ghcr.io/aggrete/aggrete --demo) runs the four-question walkthrough with no config, auth, or network, then drops into an interactive menu so you can try scenarios (a forbidden combination, individual pay, comparing colleagues, the prompt-injection shield, a wall, a blocked store) and watch each decision. Add the same command to an MCP client ({"command": "uvx", "args": ["aggrete", "--demo"]}) and it runs as a real, self-contained demo server: bundled mock hr/finance/ops tools governed by a bundled policy, plus the check and scenarios tools. Point it at your own servers with --config for the real thing.
• Refuses forbidden calls before the upstream is contacted, using a YAML policy and per-user memory that accumulates across calls and sessions.
• Ask before you act: a built-in check tool dry-runs a proposed sequence of calls and returns the decision, the rule, the clause and the remediation without fetching anything, and scenarios lists things to try. Both are answered by the proxy itself (disable with builtin_tools: false).
• Tamper-evident audit: every decision is one hash-chained JSON line. Verify with aggrete-audit audit.jsonl (breaks are reported by line number). Optionally forward each row to a SIEM (Splunk/Elastic/Datadog over HTTP, or syslog) as it is written, off the hot path, with audit_forward:.
• Selective tool exposure: walls and blocks in the policy hide tools from users who could never call them, so they are never listed.
• Output redaction: redact: masks emails, SSNs, card numbers, API keys and bearer tokens in results before they reach the model; hits are counted in the audit.
• Holds the upstream credentials itself and never forwards the caller's token to an upstream (confused-deputy safe).
• On-behalf-of credentials: mark an upstream per_user: true and each caller reaches it with their own resolved credential (from a pluggable vault or token-exchange hook), so a person's individual access is carried end to end instead of everyone sharing one master token. The upstream sees Sam, not a shared robot account.
• Tool integrity: fingerprints every upstream tool the first time it is seen and flags any later change to its description or schema (a rug pull), and scans descriptions for hidden instructions (tool poisoning). Alert or block, per tool_integrity:. Deterministic, no model in the path.
• Rate limiting: a per-user ceiling on tool calls per window (rate_limit:), shared across replicas via Redis. A denial-of-wallet and abuse control.
• Inbound secret scanning: scans tool arguments for credential-shaped strings and blocks (or masks) them before they reach an upstream (scan_inbound:), so a leaked key never leaves through a tool call.

Governing writes (egress). A tool that acts on the world (create, update, upload, post, send, share) is classified as a write and governed as egress: any write after a session has read untrusted content is refused (the prompt-injection shield), and a rule can target writes only with applies: write. This is generic across connectors, not Drive-specific. The Google Drive connector exposes governed create_<folder> tools with --allow-write; writes are fenced to the folder like reads. Classify your own connectors' write tools with write_tools: in the config.

See ROADMAP.md for what is shipped, in progress, and planned, with the community requests behind each item.

Run it

python -m venv .venv && .venv/bin/pip install mcp pyyaml pytest
.venv/bin/python -m pytest tests -q     # tests generated from coc.yaml
.venv/bin/python demo/run_demo.py       # the four-prompt sequence, end to end

It first previews the plan with the built-in check tool, then runs it for real:

=== ask first: would this plan be allowed? ===
Plan check: REFUSED.
  1. hr__recent_joiners     [hr-personnel]  ->  allowed
  2. finance__budget_roles  [finance-comp]  ->  allowed
  3. ops__oncall_draft      [ops-rota]      ->  REFUSED   COC-HR-004
     Personnel records, compensation or budget records, and operational rosters
     may not be combined to derive ... identifiable individuals.
     Fix: request a purpose-bound session from HR Privacy ...

=== now run it for real ===
turn 1  finance__headcount_plan   allowed
turn 2  finance__budget_roles     allowed   (owner emails redacted)
turn 3  hr__recent_joiners        allowed   (emails redacted)
turn 4  ops__oncall_draft         DENIED    COC-HR-004

Turn 4 is denied before the upstream call, so the on-call data is never fetched. The three domains overlap on the same people, and this call would complete the forbidden set. check reached the same verdict without fetching anything. Call aggrete__scenarios through the proxy for more to try: individual pay (min_group), comparing colleagues (self_comparison), the prompt-injection shield (flow), and tools hidden behind a wall or block.

The document is the source of truth

coc.yaml holds clause text written by the clause owner, its enforcement, and its tests. Engineering owns the compiler, not the policy.

- rule_id: COC-HR-004
  clause: >
    Personnel records, compensation or budget records, and operational rosters
    may not be combined to derive the employment status, performance, or
    planned departure of identifiable individuals.
  owner: hr-privacy@example.com
  enforce:
    - layer: accumulation
      action: deny
      type: domain_join
      domains: [hr-personnel, finance-comp, ops-rota]
      require_entity_overlap: true
      scope: user
      window: 4h
  tests:
    - {name: four_prompt_layoff_list, expect: deny, sequence: [...]}

CI fails any rule without both an allow and a deny test. Clauses that compile to nothing are worth finding. Those are the parts of your code of conduct that were never enforceable.

aggrete-lint coc.yaml --config proxy.config.yaml catches the fail-open cases the tests do not: a high-severity rule that only alerts, a wall whose until date has passed, an enforce block missing a required field, and rules whose domains no tool is mapped to (so the rule can never fire). It exits non-zero on errors, for CI.

Rule types: domain_join, entity_budget, domain_block, self_comparison, min_group (a result about fewer than k people is one person's data; pay transparency), wall (a domain open only to allowed_users, or closed to blocked_users, optionally until a date; privilege, embargoes, investigation subjects). domain_join and domain_block accept the same allowed_users, blocked_users, since, until scoping (quiet periods). self_comparison (the requester's own record plus colleagues' records in one domain. The precondition for "how do I compare"; decided post-call, since the colleague records have to be seen to be counted). arg_match decides a call from its arguments, not just its type: the same tool is fine or forbidden depending on what it is asked to do. Name tool globs in tools: and the argument conditions that must all hold in deny_when: (operators: equals, in, regex, gt, lt, exists, missing).

- rule_id: COC-DATA-010
  clause: "Bulk exports are limited to your own team."
  enforce:
    - type: arg_match
      tools: ["*__export*"]
      deny_when: [{arg: scope, in: [all, company]}]   # export scope=team is fine
      action: deny

The regex operator runs your pattern against model-supplied argument values, so keep patterns simple and anchored (avoid nested quantifiers) to sidestep catastrophic backtracking.

The built-in check tool previews arg_match rules too: pass an object instead of a bare tool name, e.g. {"tool": "crm__export", "args": {"scope": "all"}}, and the dry run reports the decision without fetching anything.

Actions: deny, alert. Start everything at alert, tune against real traffic, then flip.

How it works