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

Security/access_control_policy.md

@@ -53,7 +53,12 @@ This policy establishes mandatory requirements for granting, reviewing, and revo
 ### 3.6 Emergency / Break-Glass Access
 - Governed by [Authentication Policy §3](authentication_policy.md) (Break-glass account type) and [§2.13](authentication_policy.md) (drills).
 
-### 3.7 Enforcement
+### 3.7 AI Agent Capability Scoping
+- For AI Agent (Autonomous) accounts (per [Authentication Policy §3.1](authentication_policy.md)), RBAC role membership alone **is not sufficient** — the tool/plugin/MCP-server allow-list reachable by the agent **is** its privilege boundary and **must** be reviewed and approved with the same rigor as a role grant.  
+- A sub-agent's capability set **must** be a subset of its parent's; delegation **must not** widen scope.  
+- Agent capability grants **must** be reviewed at the same cadence as Privileged/Admin access (§3.5) given the runtime-decided, non-enumerable nature of agent action sequences.
+
+### 3.8 Enforcement
 - Violations **may** result in disciplinary action or revocation of access.  
 - Systems unable to support role-based provisioning or timely revocation **must** be remediated or formally excepted with CISO approval.
 

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 |
 
 ---
 

Security/secrets_management_policy.md

@@ -38,7 +38,8 @@ This policy is the **canonical source** for cryptographic algorithm/parameter st
 ### 2.4 Access Control
 - Access to secrets **must** follow least privilege and, where supported, just-in-time elevation.  
 - All secret retrieval **must** be logged (who, what, when).  
-- Human access to production secrets **should** be exceptional and time-bound; services **must** authenticate via managed identity/certificate rather than a retrieved static secret where the platform supports it.
+- Human access to production secrets **should** be exceptional and time-bound; services **must** authenticate via managed identity/certificate rather than a retrieved static secret where the platform supports it.  
+- **AI Agent (Autonomous) accounts** (per [Authentication Policy §3.1](authentication_policy.md)) **must not** hold a static long-lived credential equivalent to a service account password. Agent credentials **must** be short-lived and scoped to the task/session, expiring automatically at task completion — a compromised agent session should not yield a standing key an attacker can reuse after the session ends.
 
 ### 2.5 Kill-Chain Secrets (Barbell Principle)
 Secrets gating existential systems — PKI/CA root passphrases, backup/DR encryption master keys, break-glass vault master credentials, HSM activation secrets — **must** receive protection disproportionate to ordinary secrets: