feat(aiac/phase-1): Functional AIAC Agent + onboarding demo

[oblinder]

Parent

Sub-issue of the AIAC epic — #643.

Summary

Stand up a functional AIAC agent and demonstrate service onboarding (UC-1) end-to-end:
onboarding an agent and a tool causes AIAC to discover their capabilities, provision the identities
they need, and generate the access rules — read from a single written policy document. Because live
enforcement is not wired yet, correctness is shown by evaluating the generated rules against the
scenario.

Goal

Prove the core AIAC loop works: a trigger leads AIAC to model access control and emit correct
rules. Onboarding github-agent and github-tool should produce inbound and outbound rules whose
allow/deny behavior matches the written policy for each user.

Scope / Out of Scope

In scope

• A functional AIAC agent — the service that receives an onboarding trigger and runs the whole
  modeling pipeline end-to-end: classify the service, discover what it can do, provision the
  identities it needs, model access, and emit rules.
• UC-1 service onboarding for one agent (github-agent) and one tool (github-tool) — for each
  service, classify it as an agent or a tool, discover its capabilities (the agent's advertised
  skills, the tool's operations), and provision the roles and scopes it needs in the identity
  provider. Roles and scopes are inferred during onboarding, not taken from the policy.
• Reading the access-control policy from a single written document — the natural-language policy
  is a single file the agent reads in full.
• Modeling access and generating the inbound and outbound rules, then validating them by
  evaluation — the generated rules are checked against the scenario's allow/deny expectations,
  without routing live traffic.

Out of scope

• Live trigger path (identity-provider events → message broker) — the demo triggers onboarding
  directly. (Phase 2.)
• Live enforcement (runtime token exchange) — Phase 1 validates by evaluating the rules, not by
  routing real traffic. (Phase 2.)
• Writing rules into the enforcement system's Kubernetes resource — Phase 1 emits rules to a
  filesystem location. (Phase 2.)
• Searchable knowledge base — the policy is a single written document here. (Phase 3.)
• UC-2 (Policy Update) and UC-3 (Role Update). (Phase 4.)

Future work

• Showcasing the agent-role gate in outbound decisions (see the demo's outbound note) requires a
  second tool the agent is not mapped to. Deferred to a future extended demo.

---

Demo

Scenario

• Agent github-agent and tool github-tool.
• Three users: dev-user (developer), test-user (tester), and devops-user (a devops role with
  no access to this agent or its tools).

Example policy document

Written in plain language — it states user intent only. The agent's roles and the tool's operations
are not named here; AIAC infers them during onboarding.

# Access Control Policy (example)

Grant access on a least-privilege basis: allow only what this policy states; deny by default.

- Developers may read and modify source, and read issues.
- Testers may read and modify issues.

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

Two onboarding triggers, described by intent:

1. Onboard the tool (github-tool). AIAC classifies it as a tool, inspects its operations
   (discovering read/modify on source and issues), and provisions the corresponding tool scopes
   in the identity provider. A tool is a pure target, so no rules are written for it directly.
2. Onboard the agent (github-agent, identified by its workload identity). AIAC classifies it as
   an agent, reads its advertised skills (source, issues), infers the agent's roles and the
   scopes callers need, provisions them in the identity provider, then reads the written policy and
   generates the inbound and outbound rules for the agent.

sequenceDiagram
    actor Operator
    participant AIAC as AIAC Agent
    participant IdP as Identity Provider
    participant Rules as Generated Rules
    Operator->>AIAC: Onboard github-tool
    AIAC->>AIAC: Classify as tool and inspect operations
    AIAC->>IdP: Provision tool scopes for source and issues
    Note over AIAC: Tool is a pure target, no rules written
    Operator->>AIAC: Onboard github-agent by workload identity
    AIAC->>AIAC: Classify as agent and read skills
    AIAC->>IdP: Provision agent roles and caller scopes
    AIAC->>AIAC: Read written policy and model access
    AIAC->>Rules: Write inbound and outbound rules

Loading

Result: inbound rules (who may call the agent, and with what capabilities) and outbound rules
(which tool operations the agent may perform on each user's behalf). No rules exist for the tool
alone.

Part 2 — Online: validate modeling correctness (rule evaluation)

There is no live enforcement in Phase 1, so the "runtime" step evaluates the generated rules
against the scenario to confirm the modeling from Part 1 is correct.

sequenceDiagram
    actor Operator
    participant Eval as Rule Evaluator
    participant Rules as Generated Rules
    Operator->>Eval: Evaluate inbound rules per user
    Eval->>Rules: may this user use the agent?
    Eval-->>Operator: developer ✓, tester ✓ (issues only), devops-user ✗
    Operator->>Eval: Evaluate outbound rules per (user, tool operation)
    Eval->>Rules: may the agent perform this operation for this user?
    Eval-->>Operator: per-operation allow/deny matrix (below)

Loading

Inbound — may the user use github-agent?

User	Result
dev-user (developer)	✅ allow — source + issues capabilities
test-user (tester)	✅ allow — issues capabilities only
devops-user	❌ deny — no access to the agent

Outbound — may github-agent, on behalf of the user, perform an operation on github-tool?

User	source-read	source-write	issues-read	issues-write
dev-user (developer)	✅	✅	✅	❌
test-user (tester)	❌	❌	✅	✅
devops-user	❌	❌	❌	❌

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). In this scenario the agent
holds all of github-tool's scopes, so this demo exercises the user-gating dimension only; the
agent-role gate is not exercised here (see Future work).

---

Acceptance criteria

• Onboarding github-tool provisions its operation scopes; no rules are written for the tool
  alone.
• Onboarding github-agent infers its roles and caller scopes and generates inbound and
  outbound rules; the tool's scopes and the agent's roles are inferred during onboarding,
  not taken from the policy document.
• Evaluating the inbound rules matches the table above: dev-user and test-user may use
  the agent (tester limited to issues), devops-user denied.
• Evaluating the outbound rules matches the per-operation matrix above (developer allowed
  source read/modify + issues-read but denied issues-write; tester allowed issues
  read/modify but denied source; devops-user denied everything).
• The policy is 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.