feat(aiac/phase-2): Platform integration — live onboarding trigger + live enforcement

[oblinder]

Parent

Sub-issue of the AIAC epic — #643.

Depends on

• Phase 1 — feat(aiac/phase-1): Functional AIAC Agent + onboarding demo #645 complete and merged.

Summary

Connect AIAC to the live platform. Onboarding is now driven by the platform's own trigger path
(registering a client in the identity provider fires an event that reaches AIAC — no manual
trigger), and the rules AIAC generates are written where the enforcement layer can load and
apply them to real traffic. AIAC also wires the identity provider so the agent can obtain
tool-scoped tokens on each user's behalf.

Goal

The same UC-1 onboarding proven in Phase 1 now runs hands-off and enforced: creating the agent
and tool clients makes AIAC model and publish the rules automatically, and a real request is allowed
or denied — and carries only the operations the rules grant — exactly as the policy intends.

Scope / Out of Scope

In scope

• The live onboarding trigger path — registering a service as a client in the identity provider
  raises a lifecycle event that flows through the event broker to the AIAC agent, which onboards the
  service automatically. No operator triggers onboarding by hand.
• Publishing the generated rules to the enforcement layer — instead of writing to a local file,
  the agent writes the rules to the enforcement layer's policy resource, from which the enforcement
  layer loads and applies them to live traffic.
• Live enforcement of a real request — an inbound request to the agent is checked against the
  inbound rules, and the agent's onward call to the tool is checked against the outbound rules and
  carried by a scoped token exchange.
• Identity-provider wiring for token exchange — the agent is set up so a caller's token can be
  exchanged for a token scoped to the tool, carrying the correct audience and only the operations the
  rules grant.

Out of scope

• Searchable knowledge base — the policy is still a single written document. (Phase 3.)
• UC-2 (Policy Update) and UC-3 (Role Update). (Phase 4.)

Future work

• Showcasing the outbound agent-role gate (see the outbound note) needs a second tool the agent
  isn't mapped to. Deferred to a future extended demo.

---

Demo

Scenario

Same as Phase 1 — github-agent, github-tool, and users dev-user (developer), test-user
(tester), devops-user (no access) — but now driven end-to-end by the platform and enforced on live
traffic.

Part 1 — Offline: model the access control (live trigger → AIAC → rules)

1. Register the tool as a client in the identity provider. This fires a platform event that
   triggers AIAC to onboard github-tool (classify → inspect operations → provision tool scopes).
   No rules are written for the tool alone.
2. Register the agent as a client (with its workload identity). The event triggers AIAC to
   onboard github-agent (classify → read skills → provision roles + caller scopes → read the
   written policy → model access), write the inbound and outbound rules to the enforcement
   layer's policy resource, and wire the identity provider so the agent can exchange user tokens
   for tool-scoped tokens.

sequenceDiagram
    actor Operator
    participant IdP as Identity Provider
    participant Bus as Event Broker
    participant AIAC as AIAC Agent
    participant Policy as Enforcement Policy resource
    Operator->>IdP: Register github-tool client
    IdP-->>Bus: client-created event
    Bus->>AIAC: onboard github-tool
    AIAC->>IdP: Provision tool scopes
    Operator->>IdP: Register github-agent client (workload identity)
    IdP-->>Bus: client-created event
    Bus->>AIAC: onboard github-agent
    AIAC->>IdP: Provision roles and caller scopes and wire token exchange
    AIAC->>AIAC: Read written policy and model access
    AIAC->>Policy: Write inbound and outbound rules

Loading

Part 2 — Online: enforce and validate (live request flow)

A user request is routed through the enforcement layer to the agent (inbound check) and onward to
the tool via token exchange (outbound check). The exchanged token carries only the operations the
rules grant.

sequenceDiagram
    actor User
    participant PEP as Enforcement Layer
    participant Agent as github-agent
    participant Tool as github-tool
    User->>PEP: call github-agent
    PEP->>PEP: inbound check against the rules
    alt allowed for developer or tester
        PEP->>Agent: forward
        Agent->>PEP: call github-tool on the user behalf
        PEP->>PEP: outbound check and token exchange
        PEP->>Tool: forward with a token scoped to the granted operations
    else denied for devops-user or direct user to tool
        PEP-->>User: denied
    end

Loading

Request	Inbound	Token carried onward to github-tool
dev-user → github-agent	✅	source-read, source-write, issues-read
test-user → github-agent	✅	issues-read, issues-write
devops-user → github-agent	❌	none
dev-user → github-tool directly (no agent)	❌	none — no direct user→tool access

Outbound rule: an operation is allowed only when it is both in the user's permitted tool
operations and in the agent-role's tool scopes (an intersection). The agent holds all of
github-tool's scopes here, so this demo exercises the user-gating dimension only (see
Future work).

---

Acceptance criteria

• Registering a client for github-agent or github-tool triggers onboarding automatically
  through the live event path — no manual trigger.
• The generated rules are written to the enforcement layer's policy resource and loaded by
  the enforcement layer.
• The identity provider is wired so the agent can exchange a user token for a tool-scoped
  token with the correct audience and scopes; re-running onboarding is idempotent.
• Live enforcement matches the table: dev-user and test-user are allowed inbound (tester
  limited to issues), devops-user is denied, and direct user→tool access is denied.
• The exchanged token carries only the operations the rules grant for the requesting user.
• The policy is still read from a single written document; no knowledge base is involved.
• UC-2 and UC-3 are not implemented; no policy-update or role-update paths are exercised.