Skip to content

S4 — Routing, admission, and limits that hold #16

Description

@fmind

What a stranger gets: the first word picks the agent; who may ask is explicit; abuse is bounded; agents can never trigger each other through the room.

Acceptance

  1. Routing: @a4h <handle> <text> — the first token selects the handle, a trailing colon is stripped; two handles in one message route to the first, never fan out; with exactly one agent mapped, the handle is optional.
  2. Admission: per-room and per-sender allow and deny lists; external senders denied by default; policy.default: allow inside the room.
  3. Unconditional in-memory rate limits per sender and per room — no "off", no zero; startup refuses any config that would disable them.
  4. Loop prevention, enforced twice: bot- and agent-authored events are dropped before dispatch, and every a4h reply is marked machine-authored; mentions inside agent output render inert. One deterministic test proves a reply can never become an invocation.
  5. EU AI Act Art. 50(1) disclosure line, once per thread, on by default.
  6. @a4h help costs zero config: rendered from the AgentCard's required skills fields (name, description, tags) — ADK populates them automatically, kagent authors them. Card unreachable ⇒ handle + endpoint only.
  7. Invited to a room ⇒ one intro message, once: the mapped handles with their card-derived one-liners (reuses the help renderer — the onboarding pattern every hosted competitor ships). Never repeated, never unprompted afterward.
  8. The redaction sentinel test: chat content appears in no log, metric, or error output.

Non-goals

Group or OIDC identity linking · admin verbs beyond help · approval logic (a4h renders the runtime's approval, never owns it).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions