From the Campus Operations edition of September 27, 2026
Stanford AISF sets risk-tiered Self-Service/DRA pathways and mandatory agent identity for administrative AI
Stanford University (University IT) · Higher education campus IT / information security / administrative AI governance · United States (Stanford University, California; R1 research university)
- Publisher
- Stanford University IT
- Original publication
- Undated living Stanford UIT AI Security Framework page (retrieved 2026-09-27)
- Source retrieved
- 2026-09-28
What happened
Stanford University IT's AI Security Framework (AISF) establishes a risk-based shared-responsibility model for developing, deploying, procuring, and overseeing AI systems that touch Administrative data—including student records, faculty/staff information, financial records, alumni/development data, and research-administration funding. Every in-scope deployment begins with a Self-Service Deployment Checklist; High-Risk systems and non-approved third-party AI also require a Data Risk Assessment. Agents are classified Individual, Internal Workflow, or External-Facing, with lifecycle gates for identity provisioning, least privilege, logging, tested kill-switches, and decommissioning. Section 6 requires every in-scope AI agent to have an identity appropriate to its category; Internal Workflow and External-Facing agents must not run under human user credentials. The document integrates concepts from ISO 42001, NIST AI RMF, EU AI Act, AIUC-1, and OWASP AIVSS, and is framed as guidance rather than a binding policy mandate.
Why it matters
Direct campus-operations governance evidence for how a major R1 operationalizes agentic AI security over administrative systems. Why now: never archived; newly relevant complementary institutional framework the day after Vanderbilt's CIO emphasized unresolved agent identity/liability questions in the 2026-09-26 edition.
Evidence and measured results
Opened Stanford UIT HTTPS framework page with risk matrices, lifecycle tables, and agent-identity principles. Standards guidance without measured adoption KPIs.
Limitations and uncertainty
Undated living page; guidance not a policy mandate; no measured outcome metrics; Stanford-specific DRA/ISO capacity may not transfer to smaller campuses.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-09-27; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Shadow administrative AI agents access finance/HR/student data without identity, review, or kill-switch controls.
- Stakeholders
- CIO
- CISO
- Privacy/UPO
- Administrative data owners
- Service/business owners
- Discovery questions
- Which production agents act on administrative data today?
- Do Internal Workflow agents have distinct non-human identities?
- Is there a Self-Service vs high-risk review pathway?
- Who owns kill-switch authority?
- Value hypothesis
- Risk-tiered intake with mandatory agent identity can enable campus AI without a central bottleneck—effectiveness depends on local DRA capacity, not Stanford's label.
- Potential engagement
- Four-week administrative-AI intake design: classify top ten agents, draft Self-Service checklist, and define DRA triggers for High-Risk/third-party tools.
- Unsupported claims
- Guaranteed Stanford-equivalent governance maturity
- Policy mandate status for AISF
- Measured ROI from the framework alone
Pre-sales engineering
Role takeaway
- Fit
- Risk-tiered agent registry with SSO/service identities, DRA for High-Risk/third-party AI, and lifecycle kill-switch controls over administrative data.
- Architecture and integration
- Integrate intake forms with IAM for distinct agent identities, DLP/tenant controls, logging, and Data Risk Assessment workflows; default Internal Workflow column for ambiguous internal systems.
- Prerequisites
- Administrative data classification inventory
- Identity platform supporting non-human identities
- DRA/privacy review capacity
- Acceptable-use training for deployers
- Constraints
- Guidance not a binding policy
- Undated living page
- R1-scale oversight capacity assumed
- Security
- Distinct, attributable, least-privilege, revocable, renewable agent identities; no long-lived static credentials for Internal Workflow/External-Facing agents; tested kill-switch on file.
- Proof of value
- One Internal Workflow agent with distinct identity and audit trail
- Documented Self-Service vs DRA decision for a High-Risk case
- Kill-switch test recorded with ISO awareness
Delivery
Role takeaway
- Work
- Implement AI system records, category addenda, identity provisioning, monitoring/drift review, and decommissioning checklists.
- Dependencies
- IAM/ISO
- Privacy office
- Administrative data owners
- OGC/Communications for High-Risk disclosures
- Ownership
- Service/Business Owners for workflow and external agents; individual deployers for Individual Agents; CIO/CISO executive accountability.
- Skills and adoption
- Train deployers to classify risk tier and agent category accurately; teach operators to treat AI-origin markers and escalation paths as mandatory.
- Governance checkpoints
- Pre-deploy Self-Service or DRA completion
- Quarterly access review for workflow/external agents
- Re-classification on scope/tool expansion
- Acceptance criteria
- Production agents registered with category and owner
- Distinct identities for Internal Workflow/External-Facing agents
- Kill-switch test evidence on file
- Risks
- Inaccurate self-certification
- Agents still using human credentials
- Third-party High-Risk tools bypassing DRA
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Provision distinct non-human identities for internal and external-facing agents; encode Self-Service vs DRA pathway logic into intake tooling; require kill-switch and audit logging before activation; re-classify on tool/API/write-permission expansion.
Governance
Who approves, reviews and stays accountable for outcomes?
Assign Service/Business Owners for workflow and external agents; treat inaccurate self-certification as an accountability event; keep High-Risk disclosures need-to-know with OGC/Communications review.
Security and privacy
What data, permissions and controls need testing?
Administrative-data scope pulls finance, HR, and student-ops AI into DRA; least-privilege scopes and renewable credentials reduce blast radius of autonomous tool calls.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Shared-responsibility self-service aims to avoid bottlenecks that lock less-resourced units out of approved AI; High-Risk equity/bias checks are required mainly at higher tiers.
Procurement
What should contracts, pricing and exit terms secure?
Non-approved third-party AI defaults to DRA; AI features added after initial SaaS procurement are explicitly in scope—contract language should anticipate post-award AI enablement.
Operating model
Which teams own the service once it runs?
Shifts from ad-hoc shadow agents to registered, owned identities with lifecycle stages; deployers hold first-line accountability while ISO/privacy scale with risk.
Publication history
- 2026-09-27Campus Operations · Issue 204 resources
Stable resource ID: stanford-aisf-agent-identity-framework-2026