University IT
AI Security Framework (AISF)
1.1 Framework Overview
This AI Security Framework (AISF) establishes a unified, scalable, risk-based, and shared-responsibility approach to the responsible development, deployment, procurement, and ongoing oversight of AI systems across Stanford University. It integrates:
- AIUC-1: Operational AI use-case classification and tiering methodology
- ISO 42001:2023: AI Management System standard for organizational governance
- NIST AI Risk Management Framework (AI RMF): Lifecycle-oriented risk identification and management
- EU AI Act: Regulatory risk classification, transparency, and compliance obligations
- OWASP AIVSS: AI vulnerability and security scoring guidance
The framework's central design principle is risk based: deployment determination scales to the actual risk and exposure of each system. All potential AI System deployments will begin with the Self-Service Deployment Checklist, regardless of risk category classification. High-Risk AI systems must complete the Data Risk Assessment (DRA) process in addition to the Self-Service Deployment Checklist; this also applies to third-party/non-Stanford approved AI systems. This is a deliberate design choice to enable responsible AI use across the University without creating a bottleneck that halts or slows AI system deployment efforts.
Every AI system is classified by its Risk Tier (consequence severity), its Agent Deployment Category (point of action and audience exposure), and whether it is Stanford-approved/Third Party. Together, these dimensions determine the deployment pathway: Self-Service Deploy or with DRA Review.
Key Objectives:
- Enable trustworthy, compliant, secure, and accountable AI at every stage of the lifecycle.
- Empower the Stanford community to deploy AI systems responsibly through shared stewardship.
- Scale oversight to actual risk: a personal writing assistant and a student admissions screening system are not the same.
- Integrate agent identity, lifecycle management, and category-specific control requirements with the risk-tiering process rather than separately.
This framework shall be maintained as a living document and updated in response to industry regulatory changes, operational learnings, audit findings, and the evolving AI landscape.
1.2 Definition of Artificial Intelligence
For purposes of this framework, an Artificial Intelligence (AI) system is a machine-based system that, given a set of objectives, is capable of performing actions and generating outputs such as predictions, recommendations, decisions, or content that influence real or virtual environments. AI systems use models trained on data and operate with varying degrees of autonomy. This definition is consistent with ISO 42001:2023 and the EU AI Act (Art. 3(1)).
AI systems can be designed or configured as autonomous components known as agents. An AI agent pursues a goal by determining what actions to take, how to carry them out, and adjusts its next steps based on the results, rather than simply producing a single response to a single input.
This definition excludes:
- Purely rule-based systems that execute only programmed logic with no learned or adaptive component
- Traditional statistical models (regression, decision trees, linear classifiers) where the model structure is fully specified by a human and does not adapt from new data
- Business rules engines and workflow automation tools that do not incorporate machine learning
These excluded systems remain subject to Stanford's standard data management, access control, and change management requirements. They do not require AI registration or classification under this framework. Section 2.2 is the authoritative statement of scope.
2.1 Purpose
Stanford has seen substantial growth in the adoption of AI systems across research, teaching, and administrative functions. These systems frequently access sensitive institutional data and can act on that data directly, which introduces regulatory, financial, and reputational risk that the University must manage.
The Report of the AI at Stanford Advisory Committee (January 2025) called for continued AI adoption. Stanford's existing policies already address data security, privacy, and vendor risk, but they were not designed for AI's unique traits, such as acting autonomously or generating outputs from data in unpredictable ways. While this framework is not a policy or a mandate, it addresses that gap by giving the Stanford community the tools, principles, and criteria needed to make informed decisions about using AI systems.
Applying this framework helps ensure that AI systems used, built, or procured by Stanford are:
- Safe and reliable in their intended operational context
- Compliant with applicable regulations
- Transparent and explainable to affected stakeholders
- Accountable through defined roles, responsibilities, and audit trails
- Continuously monitored and improved throughout their lifecycle
What This Framework Does Not Cover
This framework addresses the security oversight of AI systems and the data they access. It does not establish or modify IRB process or human-subjects research review, academic integrity or grading policy, employment or HR determinations, research design and methodology, or disclosure and authorship practices in scholarly publications (which remain governed by individual journals, funders, and applicable University research policy). Where AI use intersects with those areas, authority remains with the applicable existing body (IRB, Faculty Senate and academic policy committees, Human Resources, Office of the General Counsel, Office of Research).
2.2 Scope of Application
This framework applies to all AI systems within the University's control that interact with Administrative data at any risk level, and any other data, including research data, that are classified as High Risk or involve PHI, such as:
- Internally developed AI models and pipelines
- AI-embedded commercial software and SaaS products, including AI features added to existing licensed tools after their initial procurement
- Third-party AI APIs and foundation models
- AI agents built using vendor-provided agent development frameworks or agent builder tools (e.g., Microsoft Copilot Studio, Google Gemini Agent Builder)
- AI systems operating on behalf of Stanford users
Exclusions:
- Low and Moderate Risk data (that is not Administrative data)
- Purely rule-based systems (e.g., if-then decision trees, spam filters using fixed keyword lists, eligibility checkers based on static criteria)
- Traditional statistical models without adaptive learning
- Business rules engines and workflow automation tools that do not incorporate machine learning (per the definitional exclusions in Section 1.2)
2.3 Governing Principles
Decisions about AI activities apply the following principles, based on the risk, impact, and context of each proposed use:
Risk-based
Oversight scales to actual risk and exposure. This is the foundational design principle of this framework. A system with minimal data access, limited autonomy, and no external audience requires minimal oversight. A system with high-stakes decision authority, data risk classified within the scope of this framework, and broad external exposure requires full institutional review.
Human-Centric Design
AI systems should augment human decision-making rather than replace human judgment in high-stakes contexts.
Accountability
Clear ownership of AI systems should exist at every stage, from design through decommission.
Transparency
AI systems should be explainable to the degree appropriate for their Risk Tier, Agent Deployment Category and affected population.
Fairness and Equity
AI systems should be regularly evaluated for bias, with attention to whether outcomes risk perpetuating discrimination.
Shared Responsibility
AI deployers hold first-line accountability for systems they deploy. Oversight scales to risk: Low Risk systems are community-managed, while High Risk systems receive institutional review (e.g. Section 3, Table 3.2.1)
Research Integrity
AI use in research should be evaluated for questions of validity, reproducibility, or research ethics. Consistent with existing University policy, IRB retains authority over human-subjects research review, and this framework does not create separate obligations in that area; researchers should check in with IRB as appropriate.
Privacy and Data Protection
All AI systems shall comply with applicable laws and regulations through data minimization, purpose limitation, and robust consent mechanisms.
Security and Resilience
AI systems shall be designed and maintained to withstand adversarial conditions, operational failures, and evolving threat landscapes. All AI tools developed, deployed, or procured by the University shall conform to Stanford Minimum Security Standards and align with recognized industry and regulatory frameworks/standards.
Information Disclosure Discipline
The technical and operational details of AI systems (vendors, datasets, infrastructure, model versions, system prompts) shall be disclosed only on a need-to-know basis consistent with the system's risk tier. Unnecessary public disclosure of these details increases Stanford's attack surface.
Continuous Improvement
These practices shall evolve with the AI landscape, regulatory changes, and operational learnings.
To enhance our assessment of AI-related risks, this framework introduces AI risk tiers that, while aligned with Stanford's Data Risk Classification, also account for an AI system's actions or tool access, influence on decisions, and level of external exposure and autonomy. The AI Risk Classification Matrix, AI Agent Deployment Categories determines the required deployment pathway in Section 4. Autonomy is the degree to which an AI system can independently make decisions and take actions, ranging from simple rule-following to fully self-directed agents that operate without human intervention. All AI systems within scope under Section 2 must be classified before deployment and reclassified whenever material changes occur.
3.1 AI Risk Classification Matrix
3.2 AI Agent Deployment Categories
In addition to the AI Risk Classification Matrix in Section 3.1, every AI system that is in scope under Section 2 must be classified into one of three Agent Deployment Categories based on its place of action and population of exposure.
3.2.1 Cross-Cutting Rules Re-classification
An agent must be reclassified if its scope, audience, or risk changes. The highest category governs in composition: When agents call other agents, the composed system inherits the controls of the highest category in the chain. An Individual Agent that invokes an External-Facing Agent is governed as External-Facing.
| Dimension | Individual Agent | Internal Workflow Agent | External-Facing Agent |
|---|---|---|---|
| Acts on behalf of | One individual | A department, function, or service | Stanford, in front of external parties |
| Credentials used | Individual user account / SSO | Service / departmental account | System account; public or authenticated endpoint |
| Data accessed | Individual's own work product | Internal Stanford systems and records | External-party inputs; selected internal context |
| Output audience | The individual user | Internal staff, faculty, students | Public, applicants, patients, donors, participants |
| Primary risk | Data exfiltration; shadow IT | Privileged action at scale; regulatory exposure | Reputational, legal, and regulatory liability |
| Blast radius | Bounded to the individual | Bounded within Stanford | Extends beyond Stanford |
| Accountable Party | The deployer (user) | Service Owner/Business Owner | Service Owner/Business Owner/Organization Leader |
This section applies only to AI systems that are in scope under Section 2. Deployers should first confirm the system is in scope under Section 2. If it is, initiate the self-service deployment checklist to determine which pathway they need to complete.
For AI system deployments, the AI deployer accepts first-line accountability by completing the self-deployment checklist. This is a meaningful, auditable act, not a rubber stamp. Deployers who self-certify inaccurately are subject to Stanford's general accountability and disciplinary standards. Refer to Administrative Guide 1.1.1.
The deployment pathway for an in-scope system is determined by the combination of three inputs: (1) the AI Risk Tier from Section 3.1, (2) the Agent Deployment Category from Section 3.2, and (3) whether the system is using a third party whose AI tools are not approved for Stanford use. This three-factor model ensures that pathway scrutiny scales to both consequence severity and exposure surface.
The following pathways are defined:
- Self-Service Deploy (Green): Completion of the self-service deployment checklist plus the applicable category addendum in Appendix B will allow for immediate deployment.
- DRA (Red): If the AI system falls into this category, the Self-Service deployment checklist plus a Data Risk Assessment (DRA) must be completed. Required for High Risk and/or Third-Party systems.
If a submission is not approved, or is approved with conditions, the reviewing body (Data Owner or ADGC) documents the specific reason and the remediation needed for resubmission. The deployer may revise and resubmit through the same pathway once the identified gap is addressed. A system that is not approved shall not be deployed, and an existing system that no longer meets its classification's requirements shall be remediated or decommissioned.
| Risk Tier | Individual Agent | Internal Workflow Agent | External-Facing Agent | Third-Party (Non-Stanford Approved) |
|---|---|---|---|---|
| Low | Self-Service Deploy | Self-Service Deploy | Self-Service Deploy | DRA |
| Moderate | Self-Service Deploy | Self-Service Deploy | Self-Service Deploy | DRA |
| High | DRA | DRA | DRA | DRA |
| # | Step | Action |
|---|---|---|
| 0 | Confirm scope | The Deployer confirms the AI system scope as defined in Section 2.2. If not in scope, no pathway is required, and the process ends here. |
| 1 | Initiate Self-Service Deployment Checklist | The Deployer completes the AI Self-Deployment Checklist Form. |
| 2 | Classify the Risk Tier | Deployer classifies the system as Low, Moderate, or High per Section 3.1, and tags its Institutional Context (Administrative, Research, Teaching, or Other). |
| 3 | Classify the Agent Category | Deployer selects Individual, Internal Workflow, or External-Facing per Section 3.2. |
| 4 | Identify build vs. buy | Internally built? Continue with category + risk tier. Third-party / SaaS / API, refer to DRA Review if it is in scope. |
| 5 | Complete category addendum | Complete the addendum specific to the Agent Category in Appendix B. |
| 6 | Deploy or submit for review | Self-Service: the deployer self-certifies and deploys immediately. DRA / Full Review: submit AI System Record and supporting evidence. |
| 7 | Receive pathway outcome | Self-Service (Green): none, deployment proceeds. (Red): DRA. |
| 8 | Monitor and re-classify | Continuous monitoring per the system's Risk Tier. Material change in scope, data, audience, or autonomy triggers re-classification. |
Every AI system in scope under Section 2.2 (including agentic AI, AI-embedded commercial software and SaaS products, third-party AI APIs, and foundation models) must progress through six lifecycle stages: Inception, Development and Configuration, Pre-Deployment Review, Deployment and Activation, Active Operation, and Decommissioning. A system that does not meet the scope defined in Section 2.2, is not subject to this framework.
Each Agent Deployment Category (Section 3.2) imposes different gates, owners, and evidence requirements at each stage. Where a system does not map cleanly to an agentic category, the Internal Workflow Agent column governs by default for internal systems and the External-Facing Agent column for systems with external exposure.
5.1 The Six Lifecycle Stages
| Stage | Individual Agent | Internal Workflow Agent | External-Facing Agent |
|---|---|---|---|
| 1. Inception | Owner: Individual deployer
| Owner: Business Owner
| Owner: Business Owner
|
| 2. Development and Configuration |
|
|
|
| 3. Pre-Deploy Review |
|
|
|
| 4. Deploy & Activation |
|
|
|
| 5. Active Operation |
|
|
|
| 6. Decommissioning |
|
|
|
5.2 Re-Classification Triggers
Any of the following changes during the Active Operation Stage require the deployer to return AI System to Pre-Deployment Review Stage for re-classification under Sections 3.1 and 3.2:
- Expansion of the data the AI system can access (new system, new data domain, new sensitivity tier)
- Addition of new tool calls, APIs, or write permissions
- Change in audience -- e.g., an Individual Agent shared with a team, or an Internal Workflow Agent exposed externally
- Material change in the underlying model (different foundation model, fine-tuning, or system-prompt rewrite affecting capability or autonomy)
- Change in operating jurisdiction or regulatory scope
- Incident or near-miss that reveals previously unknown risk
- Change that brings a previously out-of-scope system into scope under Section 2.2. Such a system must complete Stage 1 before proceeding because it had not previously been registered.
- Change in use case
Agent identity is the foundation for every other control in this framework. Without a distinct, attributable, and revocable identity, an agent cannot be authorized, audited, monitored, or decommissioned. Treating agents as anonymous extensions of human users creates serious risk and makes incident response impossible. Every agent must have a designated human or team owner who remains accountable for the actions it takes.
This framework requires every AI agent, that is in scope under Section 2.2, operating at Stanford to have an identity appropriate to its Agent Category. Identity is provisioned during Lifecycle Stage 2 (Development and Configuration), activated at Stage 4 (Deployment and Activation), and revoked at Stage 6 (Decommissioning).
6.1 Core Principles of Agent Identity
The following principles apply to all in-scope AI agents:
Distinct from any human
Internal Workflow and External-Facing Agents must operate under their own identity, not under the credentials of the deployer or any individual employee. Individual Agents are an explicit exception: they operate under the user's identity by design, which is why they have a smaller authorized scope.
Attributable
Every action the agent takes must be traceable in audit logs to the agent's identity, the human accountable for it, and the version of the model and prompt in use at the time.
Least-privilege
The identity is scoped to the minimum set of systems, data, and tools required for the agent's defined purpose. Privilege expansion requires re-classification (Section 5.2).
Revocable
The identity must be revocable in a single action by the operational owner or the ISO Team. This is the technical foundation of the kill-switch requirement.
Renewable, not persistent
Credentials and tokens issued to the identity must rotate per ISO policy. Long-lived static credentials are not permitted for Internal Workflow or External-Facing Agents.
Disclosed when interacting with people
External-Facing Agents must identify themselves as AI at the start of every interaction. Internal agents that initiate communication with humans (e.g., posting to Slack, sending email) must include a clear AI-origin marker.
6.2 Open Issues for Future Iteration
Three areas of agent identity are evolving rapidly and warrant continued attention as Stanford's in-scope agentic deployment grows:
Agent-to-agent identity
When one agent invokes another, the chain of accountability must be preserved. Stanford should require that downstream agents log the calling agent's identity, not just the originating user.
Cross-tenant identity for third-party agents
When a Stanford-deployed agent acts via a vendor API (e.g., a Salesforce agent acting on Stanford data), the identity model must distinguish actions taken by the vendor's platform from actions taken on Stanford's behalf. This should be addressed in the vendor DRA process.
Standards adoption
Emerging standards for agent identity and authorization (workload identity federation, signed agent credentials, OAuth for AI agents) should be tracked by ISO and folded into this framework during the annual review cycle.
Transparency and explainability are required at multiple levels: organizational (what AI systems are in use), system (how they work), and decision (why a specific output was produced). Requirements are scaled to the risk tier of each system.
7.1 Information Disclosure Guidance by Risk Tier of Each System
| Risk Tier | What May Be Disclosed | What Should Not Be Disclosed |
|---|---|---|
| Low | General acknowledgment that AI tools are in use; approved tool names from the Stanford AI Tools catalog; general capability descriptions. | Avoid unnecessary disclosure of specific configuration details, prompt structures, or vendor contract terms. |
| Moderate | Existence and general purpose of the system; the fact that it has been reviewed; general data categories processed. Disclosure to directly affected users as described by Section 8.2. | No public disclosure of model versions, training data sources, specific vendor configurations, or system prompt content without ISO review. |
| High | Existence of the system only, as required for regulatory compliance or mandatory AI disclosure obligations. Disclosures to regulators and auditors as required by law. | No public disclosure of architecture, vendors, datasets, model versions, access controls, or system configuration. Public statements about High Risk AI systems must be reviewed by OGC and Communications before release. |
7.2 Disclosure to Affected Individuals
- The IRB determines whether and how research subjects should be informed of AI involvement in research through the informed consent process.
- Users interacting with AI systems should be notified, where appropriate, that they are engaging with an AI system.
Effective AI oversight requires clear ownership at every level. This section defines the organizational roles, responsibilities, and decision-making authorities required to operationalize this framework for AI systems in scope under Section 2.2.
8.1 Role Definitions
| Role | Responsibility |
|---|---|
| Chief Information Officer (CIO) | Executive accountability for AI oversight |
| Chief Risk Officer (CRO) | Advises on the overall institutional risk |
| Chief Information Security Officer (CISO) | Oversees overall information security systems for AI oversight |
| Administrative Data Governance Council | Responsible for providing guidance on the use of Stanford administrative data in AI tools. |
| Data Owner | Responsible for cases where Stanford data are involved. |
| Service Owner/Business Owner | Responsible for ongoing compliance. Use-case risk classification and lifecycle management. Completes self-deployment checklist and DRA submissions if needed. |
| AI Deployer | Responsible for ongoing compliance for individual agents. Completes self-deployment checklist and DRA submissions. |
| University Privacy Officer (UPO) | Compliance and privacy review; de-identification sign-off |
| AI Engineer | Implements technical controls, tests models, and deploys AI services |
| Information Security Officer | Establishes and reviews policy. Performs vendor security reviews, security assessments, and contract reviews. |
| Organization Leader | Accountable for ensuring compliance with established standards, addressing any resulting violations, and determining disciplinary outcomes. |
- Administrative Data: Data used to support the operational and administrative functions of the University and its campus, as distinct from data supporting the University's research mission, HIPAA-covered medical data, and similar regulated categories. Includes, but is not limited to: student records (enrollment and admissions), faculty and staff information, financial records, alumni and development information, and information related to the funding and administration of research.
- Agentic AI system: An AI system that pursues goals autonomously across multiple steps, invoking tools and taking actions in the world without per-step human approval.
- Agent Deployment Category: One of three classifications (Individual, Internal Workflow, External-Facing) that captures the locus of action, credential model, and population exposed to an AI system's outputs.
- AI System: A machine-based system designed to operate with varying levels of autonomy that generates outputs such as predictions, recommendations, decisions, or content (ISO 42001 / EU AI Act).
- AI System Record: The unified document combining the registration form for every AI system. Automatically completed at intake and updated throughout the system lifecycle.
- AI Impact Assessment (AIIA): A structured evaluation of the potential risks, impacts, and mitigations for a High Risk AI system prior to deployment.
- Conformity Assessment: A procedure verifying that a High Risk AI system meets applicable requirements before it is placed on the market or put into service (EU AI Act Art. 43).
- Data Drift: A statistically significant change in the distribution of input data provided to a deployed AI model, which may degrade model performance.
- Data Risk Assessment (DRA): To safeguard sensitive information, the University Privacy Office (UPO) and Information Security Office (ISO) conduct data risk assessments (DRAs)
- Explainability: The degree to which the internal mechanics and outputs of an AI system can be understood and communicated to a defined audience.
- FERPA: Family Educational Rights and Privacy Act -- U.S. federal law protecting the privacy of student education records.
- Foundation Model: A large AI model trained on broad data at scale, adaptable to a wide range of downstream tasks (e.g., large language models, multimodal models).
- HIPAA: Health Insurance Portability and Accountability Act -- U.S. law governing the privacy and security of protected health information (PHI).
- IRB: Institutional Review Board -- the ethics committee responsible for reviewing research involving human subjects, including AI-assisted research.
- Kill switch: A mechanism allowing an authorized operator to immediately halt an agentic system's execution, releasing all acquired permissions.
- Shared responsibility: The framework in which AI deployers self-certify and take accountability for lower-risk systems, reducing the bottleneck of centralized review.
- Workload identity: A non-human identity (service account or cryptographically signed credential) used by an automated system or agent to authenticate to other systems.
