Add browsable INDEX.md, update README, and refine AI agent identity controls

Security/authentication_policy.md

@@ -117,6 +117,17 @@ This policy supports GDPR principles of **data protection by design** and **acco
 | **Third-party / Vendor** | MSP, external support, auditor with standing access | AAL2 (AAL3 if privileged or TLP:AMBER+STRICT/RED data) | Federated SSO preferred; MFA mandatory | Per role, per §2.9 | Time-bound access; contractually mandated MFA; offboarding SLA ≤ 24h from contract end |
 | **Guest / External Collaborator** | Partner, contractor without standing access | AAL2 | Federated identity or authenticator app | Session-bound to engagement | Requires internal sponsor; no standing/persistent access |
 | **Shared / Generic / System** | Legacy shared logins, kiosk accounts | **Prohibited** unless individually attributable | N/A | N/A | Requires documented exception, compensating controls, and CISO approval per §4 (Exceptions) |
+| **AI Agent (Autonomous)** | LLM-based agent, orchestrator, sub-agent, autonomous automation with tool/action access | N/A (credential-based) — governed by §3.1 capability scoping, not AAL alone | Short-lived/session-scoped credential; no static long-lived key | Task-scoped, expires at task completion | See §3.1 — this is not a Service Account with extra steps |
+
+### 3.1 AI Agent Identity — Why It's Not a Service Account
+A **Service/Machine account** runs fixed code with an enumerable, static scope: you can audit exactly what it does before granting access. An **AI Agent** decides its action sequence at runtime from a prompt plus whatever tools/data it can reach — the scope is only enumerable as "the union of everything its tools allow," not as a fixed set of API calls. It also typically acts **on behalf of** a human or another agent, and can **spawn sub-agents**, neither of which a service account does. Treat it as a distinct account type with its own control model:
+
+- **Capability/tool-scoping is the privilege boundary, not role membership.** Least privilege for an agent means least *tools* and least *data reachable through those tools* — the tool/plugin/MCP-server allow-list **must** be reviewed and approved like any other permission grant (see [Access Control Policy §3.7](access_control_policy.md)).
+- **Delegation chain must be logged end-to-end.** Every agent action **must** log the full chain — invoking human/system → orchestrating agent → sub-agent → tool call → target system — not just "agent X did Y." See [Logging, Monitoring & Retention Policy §2.1](logging_monitoring_policy.md).
+- **No standing autonomous access to the kill-chain tier (§2.1).** Actions touching kill-chain systems **must** require human-in-the-loop approval per action; autonomy is permitted everywhere else within the agent's scoped capabilities. This is the barbell applied to agents.
+- **Sub-agents must not escalate privilege.** A spawned sub-agent's tool/data access **must** be a subset of its parent's — delegation narrows, never widens.
+- **Credentials must be short-lived and session/task-scoped**, per [Secrets & Key Management Policy §2.4](secrets_management_policy.md) — no static long-lived API key standing in for the agent indefinitely, the way a service account password might.
+- **Prompt injection is a modeled threat, not an edge case.** Untrusted content the agent consumes (web pages, documents, tool output, another agent's output) **must** be treated as a potential attacker-controlled input capable of hijacking the agent's actions *within its own legitimate permissions* — a confused-deputy attack, not a credential theft. Mitigations: tool allow-listing, human confirmation gates on high-risk actions, and treating "agent + untrusted content" as a trust-boundary crossing in threat models (see [Secure SDLC Policy §2.1](secure_sdlc_policy.md)).
 
 ---
 
@@ -141,8 +152,8 @@ This policy is built to the five pillars of the organization's internal **Antifr
 | **1. Structural Decoupling** | §2.6, §2.11 | Documented IdP fallback path; 90-day vendor exit readiness — no single IdP/MFA vendor can hold the org hostage |
 | **2. Optionality Preservation** | §2.4, §2.9 | ≥2 MFA methods from independent implementations per user; ≥2 methods enrolled preserves the right to authenticate if one path fails |
 | **3. Stress-to-Signal Conversion** | §2.12, §2.13 | Every MFA bypass/outage/break-glass event forces a structural fix within 30 days; break-glass drilled quarterly with bounded blast radius and abort condition |
-| **4. Sovereign Intelligence** | §2.14 | IdP config, Conditional Access rules, break-glass procedure documented and owned — not tribal knowledge held by one admin |
-| **5. Asymmetric Payoff Design (Barbell)** | §2.1 (kill-chain tier), §3 (Account Type table) | Paranoid AAL3 concentrated on kill-chain systems (IdP, PKI roots, backup infra, break-glass vault) and privileged accounts; standard AAL2 baseline elsewhere — nothing moderate in the middle |
+| **4. Sovereign Intelligence** | §2.14, §3.1 | IdP config, Conditional Access rules, break-glass procedure documented and owned — not tribal knowledge held by one admin. An autonomous cloud-hosted agent with broad tool access is the sharpest form of the manifest's "AI leak" risk: it doesn't just process your data on infrastructure you don't control, it can **act** on it |
+| **5. Asymmetric Payoff Design (Barbell)** | §2.1 (kill-chain tier), §3 (Account Type table), §3.1 (agent kill-chain gate) | Paranoid AAL3 concentrated on kill-chain systems (IdP, PKI roots, backup infra, break-glass vault) and privileged accounts; standard AAL2 baseline elsewhere. Same logic applied to agents: human-in-the-loop mandatory at the kill-chain boundary, bounded autonomy everywhere else — nothing moderate in the middle |
 
 ---