From 2fec5e8fc4607a4621db4a59d2bb620ecd83f4c2 Mon Sep 17 00:00:00 2001 From: Tomas Kracmar Date: Tue, 7 Jul 2026 17:12:17 +0200 Subject: [PATCH] Add browsable INDEX.md, update README, and refine AI agent identity controls --- INDEX.md | 59 +++++++++++++++++++++++++++ README.md | 4 ++ Security/access_control_policy.md | 7 +++- Security/authentication_policy.md | 15 ++++++- Security/secrets_management_policy.md | 3 +- 5 files changed, 84 insertions(+), 4 deletions(-) create mode 100644 INDEX.md diff --git a/INDEX.md b/INDEX.md new file mode 100644 index 0000000..bfbec4b --- /dev/null +++ b/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).* diff --git a/README.md b/README.md index f710b57..2e685fd 100644 --- a/README.md +++ b/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: diff --git a/Security/access_control_policy.md b/Security/access_control_policy.md index 035bb0b..19139ca 100644 --- a/Security/access_control_policy.md +++ b/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. diff --git a/Security/authentication_policy.md b/Security/authentication_policy.md index 689aeeb..c1ab9ec 100644 --- a/Security/authentication_policy.md +++ b/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 | --- diff --git a/Security/secrets_management_policy.md b/Security/secrets_management_policy.md index b220aa4..29ef571 100644 --- a/Security/secrets_management_policy.md +++ b/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: