You ship software professionally and you want the rules, not the tutorial. Here they are — the account boundaries, tool tiers, data ceilings, and review bar for AI-assisted development at Notre Dame, on one screen.

The rules in one screen

Topic The rule
Accounts ND-provisioned accounts only for ND code, data, and credentials. Personal Claude/ChatGPT/Copilot accounts never touch ND work — data flows must stay inside ND's agreements.
Tools Assessed tools only (see tiers below). Check with the AI Enablement team before installing anything new — including plugins, MCP connectors, and agent skills. Anything that gives an AI new capabilities gets vendor-level scrutiny.
Data Sensitivity levels govern every prompt, file, and test fixture: Public and Internal/Sensitive per tool approval; Restricted (SSNs, payment cards, health data) never enters any AI. Code carries a classification too — config, embedded queries, and comments included.
Secrets Never in prompts or source. Environment variables and secret managers; .env gitignored with a committed .env.example. Agents with filesystem access can read .env — scope accordingly. On a leak: rotate first, report second.
Agents Limit blast radius: working-directory filesystem scope, approval required for shell/network/writes outside the project, scoped credentials (never a root key), allow-listed network.
Review AI code goes through the same PR process as any other code. Read every line; if it's too big to review in 30 minutes, it's two PRs. AI may be the first reviewer, never the only one. Sensitive paths (auth, payments, deletion): two human reviewers — AI isn't one of them.
Disclosure PR descriptions state what was AI-assisted and how it was reviewed. Your name is on the merge; you retain full responsibility for correctness, security, and maintainability.

Tool tiers at a glance

Tier Meaning Use
T1 — Enterprise Approved Contracts and data protection agreements in place. All work, when data and risk align.
T2 — Assessed (no DPA) Risk-reviewed; contractual protections incomplete. Public and Internal data only.
T3 — In Assessment Time-boxed evaluation underway. Controlled experimentation — not production.
Not Permitted No assessment, or failed assessment. Not for ND work.

The supported stack

Preferred doesn't mean only-allowed — it means the institution has invested support, governance, and a backstop there. Today that's VS Code with GitHub Copilot or Codex, backed by GitHub Advanced Security for static analysis, secret scanning, and dependency review. Gemini's Canvas mode is included with ND Google accounts, Google AI Studio is available on request, the Claude Code harness can be pointed at an approved model provider, and Portkey provides gateway API access with chargeback. The wider ecosystem of agentic IDEs and harnesses is case-by-case through assessment.

Popular tools & setups, in full

Skills and institutional context

We publish skills — machine-readable conventions your AI tooling can load — so you stop re-explaining how OIT systems are architected or how ND interfaces should behave. Drop them into your project context (CLAUDE.md / AGENTS.md) and the AI starts from our standards instead of generic ones.

The skills repository is being prepared for publication. Until then, browse the catalog in the Toolkit and contact the AI Enablement team for early access. Keep re-explaining the same convention to your AI? Tell us — that's a skill candidate.

Before you ship: three questions

  1. Which lane am I in? Exploring, piloting, or actually in production for real users?
  2. What's the data classification? Public, Internal, Sensitive, or Restricted — of the data and the code.
  3. Has it been reviewed for the lane it's in? Not the lane you wish it were in.

Apps that need university resources — Okta SSO, OIT-managed AWS, institutional data integrations — will meet defined requirements. Engage early; it's cheaper than retrofitting. Ownership & responsibilities has the details.