Skip to content

design: GuardAgent output interception plane (PII, schema, rate-limit, content policy) #947

Open

Description

@vybe

Summary

Design and prototype a platform-level output monitor that sits between agent completion events and their destinations (users, downstream agents, channels). Resolves target architecture open question #3: where the rule-based vs LLM-based evaluation boundary lives.

Context

docs/planning/TARGET_ARCHITECTURE.md §"GuardAgent" describes the destination capability — PII detection, output schema validation, external-call rate limiting, content policy enforcement — and §"Key Open Questions" #3 names the unresolved decision: rule-based (regex, schema) is implementable today; LLM-based semantic quality scoring is more powerful but adds latency and cost. The boundary between them must be designed before any GuardAgent ships.

GuardAgent intercepts at the event bus (#306) between agent completion and subscriber delivery, so it does not require changes to the agent runtime — but it does require a stable completion event contract, which Sprint D′ (#524 state machine) is still hardening.

Acceptance Criteria

  • Design document under docs/planning/ (proposed: GUARDAGENT_DESIGN.md) covering:
  • Prototype the rule-based tier only (PII regex, schema validation against agent's declared output contract). Defer LLM tier to a follow-up issue.
  • Demo: an agent emits an output containing a fake SSN; GuardAgent blocks delivery to external channel and pushes to operator queue.

Technical Notes

  • This is post-Sprint-D′ work — depends on feat: agent-authoritative execution state machine with single-writer projection (RELIABILITY-005) #524 projector landing so completion events are canonical.
  • Output schema validation needs an agent-side contract in template.yaml (output_schema: field). Define that schema in this issue or a sibling.
  • Per target arch: opt-in per agent initially, opt-out for system agents.
  • Rate limiting on external API calls initiated from agent outputs may need to live elsewhere — flag if so.

🤖 Generated with Claude Code

Activity

  1. Keesan12 commented on May 26, 2026

    @Keesan12

    This looks like a coordination or scheduling contract issue. I’d make the envelope or schedule semantics visible in one place before layering on more behavior. I’d keep the fix small, explicit, and testable so the next failure is visible instead of silent. If there is already a path to a repro, I would keep the fix aligned to that instead of widening scope. If this is useful, I can help turn it into a compact repro checklist or PR shape.

  2. added
    complexity-mediumComplexity: medium (board points 5-8)
    status-incubatingIdea under consideration — pre-Todo, not yet greenlit for development
    on Jun 12, 2026
  3. self-assigned this
    on Jul 3, 2026
  4. added
    complexity-highComplexity: high (board points 13)
    and removed
    complexity-mediumComplexity: medium (board points 5-8)
    on Sep 2, 2026
  5. vybe commented on Sep 24, 2026

    @vybe
    ContributorAuthor

    Ruling 2026-09-24: stays incubating behind trinity-enterprise#165 (output credential-leak redaction — promoted to ready today) in the security-hardening workstream. This issue is the broader design pool (PII / schema / rate-limit / content policy) that follows once the concrete case ships. Clearing the stale assignment so it does not read as owned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    complexity-highComplexity: high (board points 13)priority-p3Nice-to-havestatus-incubatingIdea under consideration — pre-Todo, not yet greenlit for developmenttheme-securityTheme: Securitytype-featureNew functionality

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions