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

INDEX.md

@@ -0,0 +1,59 @@
+# Policy and Guidance Index
+
+This page provides a browsable index of all organizational policies and implementation guidance in this repository.
+
+## Security
+
+Policies and practical guidance for information security, identity management, data protection, and cybersecurity operations.
+
+### Identity, Access, and Authentication
+
+| Document | Type | Description |
+|----------|------|-------------|
+| [Authentication Policy](Security/authentication_policy.md) | Policy | Normative requirements for authenticator assurance levels, MFA, and session management. |
+| [Authentication Guidance](Security/authentication_guidance.md) | Guidance | Practical hardening guidance for authentication systems and services. |
+| [Access Control Policy](Security/access_control_policy.md) | Policy | Requirements for granting, reviewing, and revoking access to organizational resources. |
+| [Access Control Guidance](Security/access_control_guidance.md) | Guidance | Implementation guidance for role-based access control and least privilege. |
+| [Password Policy (Generic)](Security/password_policy_generic.md) | Policy | System-agnostic password and authenticator policy. |
+| [Password Guidance (Generic)](Security/password_guidance_generic.md) | Guidance | System-agnostic password implementation guidance. |
+| [Password Policy (Microsoft 365 / AD)](Security/password_policy_m365_ad.md) | Policy | Microsoft 365 and Active Directory password and authenticator policy. |
+| [Password Guidance (Microsoft 365 / AD)](Security/password_guidance_m365_ad.md) | Guidance | Microsoft 365 / Active Directory password implementation guidance. |
+
+### Data Protection and Classification
+
+| Document | Type | Description |
+|----------|------|-------------|
+| [Data Classification Policy](Security/data_classification_policy.md) | Policy | Requirements for classifying organizational data by sensitivity. |
+| [Data Classification Guidance](Security/data_classification_guidance.md) | Guidance | Practical guidance for applying data classification labels and handling rules. |
+| [Data Retention and Disposal Policy](Security/data_retention_disposal_policy.md) | Policy | Requirements for retaining and securely disposing of data. |
+| [Data Retention and Disposal Guidance](Security/data_retention_disposal_guidance.md) | Guidance | Implementation guidance for retention schedules and secure disposal methods. |
+
+### Security Operations
+
+| Document | Type | Description |
+|----------|------|-------------|
+| [Incident Response Policy](Security/incident_response_policy.md) | Policy | Requirements for detecting, reporting, and responding to security incidents. |
+| [Incident Response Guidance](Security/incident_response_guidance.md) | Guidance | Playbooks and practical guidance for incident handling. |
+| [Logging and Monitoring Policy](Security/logging_monitoring_policy.md) | Policy | Requirements for security logging, monitoring, and alerting. |
+| [Logging and Monitoring Guidance](Security/logging_monitoring_guidance.md) | Guidance | Implementation guidance for log sources, SIEM, and detection rules. |
+| [Vulnerability and Patch Management Policy](Security/vulnerability_patch_management_policy.md) | Policy | Requirements for vulnerability identification, prioritization, and remediation. |
+| [Vulnerability and Patch Management Guidance](Security/vulnerability_patch_management_guidance.md) | Guidance | Practical guidance for patch deployment and exception handling. |
+| [Secrets Management Policy](Security/secrets_management_policy.md) | Policy | Requirements for storing, rotating, and protecting secrets and credentials. |
+| [Secrets Management Guidance](Security/secrets_management_guidance.md) | Guidance | Implementation guidance for secret vaults, rotation, and injection. |
+
+### Governance, Risk, and Compliance
+
+| Document | Type | Description |
+|----------|------|-------------|
+| [Acceptable Use Policy](Security/acceptable_use_policy.md) | Policy | Rules for acceptable use of organizational systems, networks, and data. |
+| [Acceptable Use Guidance](Security/acceptable_use_guidance.md) | Guidance | Practical guidance for interpreting and enforcing acceptable use rules. |
+| [Vendor Risk Management Policy](Security/vendor_risk_management_policy.md) | Policy | Requirements for assessing and managing risks from third-party vendors. |
+| [Vendor Risk Management Guidance](Security/vendor_risk_management_guidance.md) | Guidance | Implementation guidance for vendor assessments and due diligence. |
+| [Secure SDLC Policy](Security/secure_sdlc_policy.md) | Policy | Requirements for integrating security into the software development lifecycle. |
+| [Secure SDLC Guidance](Security/secure_sdlc_guidance.md) | Guidance | Practical guidance for secure design, coding, testing, and deployment. |
+| [Business Continuity and Disaster Recovery Policy](Security/business_continuity_dr_policy.md) | Policy | Requirements for continuity planning and disaster recovery. |
+| [Business Continuity and Disaster Recovery Guidance](Security/business_continuity_dr_guidance.md) | Guidance | Implementation guidance for continuity plans, backups, and recovery testing. |
+
+---
+
+*For contribution guidelines and licensing, see [README.md](README.md).*

README.md

@@ -17,6 +17,10 @@ This repository is organized into categories of policies to facilitate easy navi
 
 *Additional categories may be added as needed.*
 
+## Browsing Policies
+
+A complete, browsable index of all policies and guidance documents is available in [INDEX.md](INDEX.md).
+
 ## Contribution Guidelines
 
 We welcome contributions to improve and update organizational policies. To propose changes or additions:

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: