Security Policy – Aligned Institute

Aligned Institute Security Policy

Entity: Aligned Sovereign Intelligence Institute (“Aligned Institute”; “ALI”) and the Governance Protocol (“ASIP”) — aligned-institute.com
Version: 3 | Date: April 8, 2026
Authors: Dr. Gabriel Axel Montes, Anthony Monroy
Status: Public-facing statement of security principles, posture, and commitments
Cross-Reference: This document defines strategic security principles. For tactical implementation details, controls, runbooks, and metrics, see the Operational Security Plan v3.0 Data Room Document (February 2026).

Preamble

Trust cannot be earned through alignment claims alone. If the evidence, governance, and infrastructure behind those claims can be corrupted — by unauthorized access, accidents, or negligence — then “alignment” is a story, not a reality.

ALI’s Operational Security Plan defines how we protect the systems, data, measurements, and governance processes that our alignment posture depends on. It is the companion to the ALI Alignment Statement, and the two documents share foundational primitives: openness-aware asset classification, evaluation and governance integrity, agentic control planes, privacy-preserving observability, and incident response compatible with decentralized governance.

This document establishes principles and commitments. The Operational Security Plan v3.0 defines the operational specifics: controls, runbooks, roles, evidence requirements, and metrics.

1. Security Is a Precondition for Alignment

ALI treats security as alignment-critical — not as a compliance afterthought.

If evaluation pipelines can be tampered with, benchmark results are untrustworthy. If governance processes can be subverted, funding decisions lose legitimacy. If release artifacts can be poisoned, open-source contributions become attack vectors instead of public goods. If private data is mishandled, the trust ALI asks of researchers and participants is betrayed.

Security is the enforcement layer that keeps alignment evidence honest, governance processes intact, and sensitive assets protected. Every security commitment in this document exists to make the alignment commitments in ALI’s Alignment Statement credible in practice.

2. What “Security” Means at ALI

ALI’s security posture is organized around two primary pillars and an openness-aware model that reflects the reality of being an intentionally open-source, decentralized organization.

The Two Pillars

Data protection — confidentiality where required; integrity everywhere. Not all data needs to be secret, but all data that matters needs to be trustworthy, and data that is genuinely sensitive must be protected with controls proportional to the harm of its exposure.

Access controls — the right people and systems, accessing the right resources, at the right time, with evidence. Identity is the control plane. Every environment, tool, and sensitive operation should know who is acting, whether they are authorized, and whether there is a record.

These two pillars are the foundation. Everything else — network controls, logging, incident response, supply chain integrity, agentic runtime security — exists to make data protection and access controls true in practice across ALI’s ecosystem.

Openness-Aware Security

ALI is not a frontier lab guarding proprietary model weights. ALI is an open-source research funding organization that publishes its outputs, operates transparent governance dashboards, and requires funded research to remain public. Importing blanket-secrecy security language into this context would create contradictions and undermine the transparency that is core to ALI’s mission.

ALI therefore adopts an openness-aware security model built on a simple distinction:

Public artifacts — open-source code, benchmarks, dashboards, funded research outputs, governance decisions — are intentionally open. The primary security objective for public artifacts is integrity and provenance: ensuring that what is published is authentic, untampered, and traceable to its source. This means signed releases, reproducible builds, tamper-evident logs, and clear provenance chains.

Non-public assets — signing keys, treasury key material, private applicant data, pre-publication work, privileged credentials, proprietary Signals platform data — must remain controlled. The primary security objective for non-public assets is confidentiality, access control, and auditability: ensuring that access is restricted to authorized parties, that actions are logged, and that exposure is minimized.

This two-lane model is the backbone of ALI’s data classification. Controls scale with sensitivity: public data gets integrity protections; internal data gets need-to-know access; restricted data (PII, proprietary analytics, API keys) gets strong access control and audit trails; critical data (treasury keys, root credentials) gets hardware-backed protection and ceremony-based access.

3. What We Protect — ALI’s Security Surfaces

ALI is an ecosystem, not a single application. Its security posture must cover several distinct surfaces, each with its own risk profile:

Protocol and Governance

On-chain governance decisions are public by design, but the keys and processes that authorize those decisions require the highest protection. Treasury operations use multi-signature wallets with independent key holders, and major governance participants undergo identity verification (KYC/AML). The integrity of governance is not just a security concern — it is an alignment concern, because governance capture undermines every downstream safety claim.

Grant Program (Pre-Launch)

Funded research outputs will be required to be open-source, but applicant data — personal information, KYC/AML records, contracts, payout details — is private and subject to data protection obligations including GDPR. Security here means protecting researcher privacy while ensuring that the public outputs they produce are authentic and unmodified.

Validator Access Model: Validators in the AIC private pool and ABC public pool will verify research milestones by accessing researcher outputs. ALI makes no claims to data ownership — researchers retain full IP rights. ALI provides validators with time-boxed, READ-ONLY access solely for verification purposes. All validator access is logged to audit trail.

Signals Platform

ALI’s data intelligence platform for AI risk handles proprietary execution logs, derived risk metrics, autonomous agent operations, and paid customer access. Data integrity is enforced through cryptographic lineage — hash-linked records from raw logs through to published metrics — so that any consumer of Signals data can trace its provenance. Access controls enforce tiered restrictions, and agent runtime environments are sandboxed.

CloudX Research Environments

ALI provisions secure, multi-cloud research environments for grant teams across AWS, Azure, and GCP. These environments must be researcher-friendly — fast to set up, cost-controlled, and free of unnecessary bureaucracy — while maintaining baseline security controls that protect both the researcher’s work and ALI’s infrastructure.

Security must be policy-symmetric across clouds: the same security objectives (MFA enforcement, encrypted storage, egress controls, budget limits) apply regardless of cloud provider, even though each cloud implements these objectives via different primitives (AWS IAM ≠ Azure RBAC ≠ GCP IAM).

Researcher-Cloud Operator Reality: Researchers are not cloud security operators. By using CloudX, researchers already rely on third-party infrastructure (AWS/Azure/GCP) for compute and storage. ALI’s security controls are an extension of that reality, not a contradiction. ALI maintains security policy consistency while respecting that the underlying cloud provider is already a trusted third party.

Open-Source Development and Releases

Public repositories, datasets, benchmarks, and dashboards are attack surfaces for supply chain compromise, tampering, and malicious contributions. ALI treats open-source integrity as a core security domain, not an afterthought.

Evaluation and Alignment Measurement Infrastructure

Benchmarks, scoring logic, and evaluation harnesses are the evidence base for alignment claims. ALI treats corruption of evaluation infrastructure — through data poisoning, benchmark gaming, or unauthorized modification — as a direct threat to its mission.

4. Core Security Principles

4.1 Controls Scale with Sensitivity

Not every asset needs the same protection. ALI classifies data and systems into tiers — from public through internal, restricted, and critical — and calibrates controls accordingly. Public artifacts need integrity and provenance. Restricted data needs strong access controls and audit trails. Critical assets (treasury keys, signing keys) need hardware-backed protection and multi-party ceremony-based access.

This is not a one-size-fits-all posture. It is a deliberate choice to apply strong controls where they matter most and avoid imposing unnecessary friction where openness is the point.

4.2 Cross-Cloud Policy Symmetry

ALI’s security posture must transcend individual cloud providers. Researchers and operators should not encounter fundamentally different security outcomes on AWS versus Azure versus GCP.

The Reality: Each cloud has different primitives:

Identity: AWS IAM ≠ Azure RBAC ≠ GCP IAM
Logging: CloudTrail ≠ Azure Monitor ≠ Cloud Logging
Networking: VPC ≠ VNet ≠ VPC (different models)

ALI’s Approach: Security controls are defined as cloud-agnostic objectives (e.g., “MFA required,” “storage encrypted,” “egress restricted”) and implemented via infrastructure-as-code with a mapping matrix that translates objectives into cloud-specific configurations. ALI and its partners strive for policy symmetry — achieving the same security outcomes through different cloud-native mechanisms.

This design ensures that security is not dependent on the expertise of a single provider, that environments can move between clouds without security regression, and that security operators can apply the posture consistently without tribal knowledge.

4.3 Researcher-First Security

Security must serve the research mission, not obstruct it. ALI designs its security controls to be the reason researchers trust the environment — not the reason they avoid it.

In practice, this means: fast onboarding with clear identity and compliance gates; pre-approved “lanes” for common research activities (accessing package managers, model hubs, and artifact registries) so that default-deny egress does not block routine work; clear, short documentation rather than compliance manuals; and a fast-turnaround exception workflow for non-standard needs.

The goal is that a grant team receiving $100,000 in funding can move from acceptance to a working, secure environment without security becoming a bottleneck — and that the security controls in place protect both the researcher’s work and ALI’s infrastructure by default.

4.4 Secure-by-Default, Not Secure-by-Surprise

ALI’s managed CloudX environments ship with security controls active — not as optional add-ons that researchers must discover and enable. Identity federation, MFA, encrypted storage, restricted egress, logging, and budget controls are baseline features of every CloudX environment. Researchers inherit a secure posture automatically and can request adjustments through documented channels.

This extends to the transition from research to production. If a team wants to stand up a service from their research environment, the same identity, egress, and logging model applies — with a “production profile” that tightens controls without requiring a rewrite. Security is not throwaway scaffolding.

4.5 Default-Deny Egress with Research Lanes

Data leaving ALI environments is controlled by default. The posture is deny-by-default for sensitive environments, with pre-approved allowlists covering the destinations researchers commonly need — registries, model hubs, cloud storage, and package managers.

Research outputs are meant to be published. Secrets, private applicant data, and proprietary Signals data are not. Egress controls focus on preventing the wrong things from leaving — keys, PII, proprietary analytics — not on preventing the publication of research. Where additional egress paths are needed, researchers use a documented exception workflow with a fast turnaround commitment.

This approach also serves as a cost-governance mechanism: deny-by-default egress prevents surprise billing and makes cost overruns visible early.

4.6 Identity Is the Control Plane

All access to ALI systems, environments, and sensitive operations flows through identity models with strong multi-factor authentication:

Signals Platform: Sovereign JWT authentication (no third-party auth providers)
CloudX Environments: Federated identity via cloud provider SSO (AWS IAM, Azure AD, GCP Workload Identity)

No shared admin accounts. Role-based access control for human access; managed service identities for machines. Privileged access is short-lived, approval-gated, and session-logged.

The joiner/mover/leaver lifecycle is a security-critical process: onboarding establishes identity and provisions minimum-necessary access; role changes adjust permissions; offboarding revokes access and rotates relevant credentials. This lifecycle covers everyone in the ecosystem — board members, staff, grant recipients, contractors, vendors, Signals customers, and validators.

4.7 Integrity and Provenance for Public Artifacts

In an open-source, decentralized organization, the most important security property for public artifacts is not secrecy — it is authenticity. Users and researchers must be able to verify that code, benchmarks, datasets, and dashboards published by ALI are genuine and untampered.

ALI commits to:

Signed releases, protected branches, and code review for all repositories
Artifact signing and SBOM generation for significant releases
Provenance and tamper-evidence practices that progress toward SLSA-style assurances over time
Minimum governance standards for any ALI-affiliated repository

ALI will also publish a vulnerability disclosure policy (SECURITY.md) and maintain coordinated disclosure processes for all public code, because secure open-source requires a clear channel for reporting and resolving vulnerabilities.

4.8 Supply Chain Integrity

Open-source and decentralized architectures expand the supply chain attack surface. Malicious dependencies, compromised build pipelines, poisoned containers, and tampered datasets are realistic threats — particularly for an organization that both consumes and publishes open-source artifacts at scale.

ALI treats supply chain integrity as a core security domain. This includes:

Automated scanning for dependency vulnerabilities, secrets, and malware
Container and base-image governance
Provenance capture for critical inputs (datasets, model weights, base containers)
CI/CD hardening with secret isolation and least-privilege runners
Dependency update strategies for all ALI-affiliated repositories

4.9 Agentic Runtime Security

ALI operates autonomous agents (in the Signals platform and potentially in future systems) and funds research that involves agentic workflows. Agents that use tools, access networks, and process untrusted inputs are a distinct security risk class — one where traditional access controls must be extended to cover non-human actors.

ALI’s posture for agentic systems requires:

Sandboxed execution environments (container or equivalent isolation)
Explicitly scoped tool permissions following the principle of least privilege
Controlled and observable network egress from agent environments
Restricted secrets access (no direct exposure unless explicitly required and approved)
Documented mitigations for prompt injection, tool misuse, and excessive agency in any LLM-and-tools component

This domain is shared between the security and alignment postures. The ALI Alignment Statement treats agentic control planes — capability permissions, budgets, logging, rollback, and circuit breakers — as alignment infrastructure. The security posture ensures those controls are enforced, not merely aspirational.

4.10 Privacy-Preserving Observability

Security and alignment both require monitoring, logging, and evidence. But observability that collects too much personal data creates its own risks — regulatory exposure, trust erosion, and a surveillance posture incompatible with ALI’s values.

ALI commits to privacy-preserving observability:

Log what is needed for security, safety, and operational integrity
Pseudonymize user identifiers — use one-way hashes so same user always gets same pseudonym
Automated PII redaction — pattern-based detection of emails, IP addresses, API keys, etc.
Redact rather than reproduce — email “[email protected]” becomes “[email protected]” (keep domain for context, hash local part)
Tie retention periods to explicit risk and operational needs (security events: 2 years; access logs: 6 months; application logs: 30 days)
Apply data protection standards to security logs themselves, especially where those logs touch PII or KYC-adjacent data
GDPR-compliant deletion workflows — automated purge of expired logs; fast-turnaround erasure requests (<72 hours)

Why This Matters: Traditional security logging captures everything, including personally identifiable information. ALI’s approach protects both security and privacy by logging security-relevant events (who accessed what, when) while minimizing exposure of personal details.

4.11 Incident Response Compatible with Decentralized Governance

ALI must be able to act quickly during a security incident — including incidents that affect multi-tenant CloudX environments, Signals platform data, or governance infrastructure. At the same time, ALI is not a centralized authority that can act unilaterally without accountability.

The Tension: Decentralized governance (requiring multi-signature consensus) is SLOW. Security incidents require FAST response. These are fundamentally in tension.

ALI’s Resolution: Time-Boxed Emergency Authority with Separation of Powers. During an active incident, designated responders can take containment actions within defined boundaries:

Emergency Authority (2-of-5 Board Emergency Multi-Sig):

Scope: Rotate credentials (JWT keys, API keys, cloud IAM), isolate systems, suspend services, revoke access
Boundaries: CANNOT access treasury funds (separate 3-of-5 multi-sig), cannot make governance decisions, cannot modify grants
Time Limit: 4 hours for P0 (critical), 24 hours for P1 (high), 7 days for P2 (medium)
Automatic Expiration: Emergency actions automatically revert after 7 days unless the board ratifies them via the standard 3-of-5 governance multi-sig

Why This Works

Separation of Keys: Emergency 2-of-5 multi-sig uses DIFFERENT keys than treasury 3-of-5 multi-sig. Emergency responders protect systems but cannot steal funds.
Bounded Scope: Emergency authority covers only containment, not governance or financial decisions.
Mandatory Transparency: All emergency actions logged to immutable audit trail within 1 hour. Public disclosure within 24 hours.
Board Ratification: Emergency actions subject to post-incident review. Board votes to ratify (make permanent) or revert.

If <2 board members are reachable during an incident, responders cannot invoke emergency powers (falls back to standard security team response).
If 2+ malicious board members collude, they could abuse emergency powers (mitigated by public logging, automatic expiration, and external audits).

ALI commits to disclosing material security incidents promptly and honestly, with enough detail for affected stakeholders to assess impact and take appropriate action.

4.12 Operational Security by Design

ALI’s security posture is designed to be operated consistently by both internal teams and qualified third-party providers. This means:

The posture is expressed as repeatable runbooks and codified policies (Terraform IaC, policy-as-code)
Operator access is scoped, logged, and regularly reviewed
Operators can execute routine security operations without ALI staff in the loop
ALI retains authority over risk acceptance decisions, policy changes, and access to critical-tier assets

CloudX Context: Researchers already rely on third-party infrastructure (AWS/Azure/GCP) for compute and storage. ALI’s security operations are an extension of that model — maintaining consistent policy enforcement across clouds while respecting the researcher’s sovereignty over their work and the underlying cloud provider’s role.

5. Protocol and Treasury Security

ALI’s protocol and treasury operations are security-critical in ways that go beyond typical organizational IT.

Treasury is managed via multi-signature wallets requiring approval from multiple independent key holders. Signing keys and treasury key material are protected with hardware-backed custody and ceremony-based access procedures. Separation of duties is enforced between key holders and between operational and governance roles. Transaction controls and anomaly detection are applied to treasury operations.

Key Innovation (v3.0.0): Emergency response keys (2-of-5 for incident containment) are SEPARATE from treasury keys (3-of-5 for financial operations). This ensures emergency responders can protect systems during incidents without gaining access to funds.

Identity verification (KYC/AML) serves as a security boundary for grant recipients and major governance participants, consistent with ALI’s compliance posture and public statements.

These controls exist because protocol integrity is alignment integrity. If the funding mechanism that directs capital toward safety research can be compromised, the entire mission is undermined.

6. How ALI Makes This Real

ALI operationalizes security through six practical commitments:

6.1 Classify and Protect Proportionally

All ALI data and systems are classified by sensitivity, and controls scale accordingly — from integrity protections for public artifacts to hardware-backed custody for critical keys. This classification is maintained and reviewed, not asserted once and forgotten.

6.2 Define Once, Enforce Everywhere

Security controls are expressed as cloud-agnostic objectives, implemented via infrastructure-as-code, and applied consistently across all cloud providers and CloudX environments. Drift from baseline is detected and remediated.

6.3 Secure the Researcher Experience

CloudX environments ship with security by default — identity federation, encryption, egress controls, logging, and cost governance. Onboarding is a defined workflow from identity verification through environment handoff. Security is part of the value proposition, not an obstacle.

6.4 Protect the Evidence

Evaluation infrastructure, benchmarks, governance dashboards, and release artifacts are treated as security-critical assets. Integrity and provenance controls ensure that alignment evidence cannot be silently corrupted.

6.5 Constrain Agents, Not Just Humans

Agentic systems operate under explicit capability permissions, sandboxed environments, controlled egress, and documented mitigations for AI-native threats (prompt injection, tool misuse, excessive agency). Agent security and alignment share the same control primitives.

6.6 Operate Transparently Under Pressure

Incident response is fast but bounded — time-boxed emergency actions with logging, post-incident review, and stakeholder disclosure. Security governance is explicit: risk acceptance authority, exception approval processes, and operator boundaries are documented, not improvised.

7. Relationship to Companion Documents

This Security Statement defines principles and posture.

ALI Alignment Statement

The companion ALI Alignment Statement defines the alignment principles that this security posture exists to protect — including shared primitives:

Openness-aware asset classification
Evaluation and governance integrity
Agentic control planes
Privacy-preserving observability
Incident response compatible with decentralized governance

ALI Operational Security Plan v3.0

The ALI Operational Security Plan v3.0 (February 2026) defines the operational “how”:

Part I: Architecture & Threat Model

Complete ecosystem diagram (Signals Platform + CloudX + Grant Verification)
Mission-critical asset classification
Top 10 threat vectors prioritized

Part II: Technical Security Framework

Application-level security (Frontend, Backend API, Sensors)
CloudX multi-cloud infrastructure (AWS/Azure/GCP IaC, cross-cloud drift detection)
Database security (encryption, RLS, backups)
Network security (WAF, segmentation, egress controls)
Dependency & supply chain security (scanning, SBOM, container governance)

Part III: AI Alignment & Safety Framework

Autonomous agent alignment principles
Prompt injection defense and sandboxing
Testing integrity (Merkle trees, cryptographic signing)
Reproducibility framework
Misuse prevention (customer vetting, privacy-preserving logging)

Part IV: Organizational Alignment

Mission coherence and ethics review board
Governance alignment (board accountability, multi-sig treasury)
Stakeholder coordination (researchers, investors, regulators, validators)
Grant program privacy framework (pre-launch)

Part V: Implementation Roadmap

Year 1 quarterly priorities (Q1-Q4 2026)
Week-by-week initiatives with owners and success metrics
CloudX deployment milestones
Grant program launch checklist

Part VI: Metrics & KPIs

Security metrics (MTTD, MTTR, CVE counts)
AI safety metrics (jailbreak rates, reproducibility)
Governance metrics (voter turnout, transparency scores)
CloudX operational metrics (drift detection, researcher onboarding time)

Part VII: Risk Register & Contingency Plans

Top 10 risks with likelihood/impact
Detailed incident response scenarios
Emergency authority workflows

Part VIII: Appendices

Glossary, contact information, reference documents
Compliance checklists (pre-launch security review, governance review)

8. Version History

v3.0 (April 10, 2026): Renamed ASI → ALI throughout document. Document renamed from “ASI Security Statement” to “ALI Security Statement”. Added cross-references to ALI Operational Security Plan v3.0 throughout.
v2.0 (February 20, 2026): Renamed ASI2 → ASI throughout document. Document renamed from “ASI2 Security Statement” to “ASI Security Statement”. Added comprehensive CloudX multi-cloud research environments as core security surface. Clarified cross-cloud policy symmetry (security objectives mapped to cloud-specific implementations). Updated grant program status to pre-launch with validator access model. Enhanced privacy-preserving observability with specific PII redaction techniques. Significantly expanded incident response section with emergency authority separation model. Added cross-references to ALI Operational Security Plan v2.0 throughout. Clarified researcher-cloud operator reality (security as extension of third-party infrastructure).
v1.0 (February 19, 2026): Initial public-facing security statement (published as “ALI2 Security Statement v1.0”). Established two-pillar model (data protection + access controls). Defined openness-aware security approach. Outlined core principles and security surfaces.

9. Contact & Governance

Security & Governance Contact: [email protected]

Privacy / GDPR Contact: https://aligned-institute.com/privacy-policy/

Document Approval:

Chief Legal Officer
Chief Science Officer
Chief Technology Officer

Public Transparency:

This document is published at https://aligned-institute.com/security
Quarterly security metrics dashboard: upon protocol launch
Incident reports and postmortems: upon protocol launch

This document will be versioned. The ALI Operational Security Plan v3.0 operationalizes the commitments made here. The companion ALI Alignment Statement defines the alignment principles that this security posture exists to protect.

Document: ALI Security Statement v3 | Status: Public-facing statement of security principles, posture, and commitments | Supersedes: v2.0 (February 20, 2026) | Companion documents: Operational Security Plan v3.0, Alignment Statement