Skip to content

Generative AI Usage Policy

This policy sets the rules for using generative AI tools in our work. It applies to everyone in UIS DevOps, and to anything produced with AI assistance: code, documentation, configuration, images, code reviews and any other output.

It says how to disclose AI use, which tools you may use, what human review AI output needs, and how to keep secrets, credentials and personal data away from AI tools.

1. Disclose AI use

Due to university policy, all project assets that have been generated or assisted by AI must be disclosed. This applies to code, documentation, images, configuration, and any other content produced with AI assistance. Disclose it with an Assisted-by trailer in the Git commit message, partly following the policy for using coding assistants when contributing to the Linux kernel:

Assisted-by: AGENT_NAME:MODEL_VERSION

Where:

  • AGENT_NAME is the name of the AI tool, for example Claude Code or GitLab Duo
  • MODEL_VERSION is the specific model version used

For example:

Assisted-by: Claude Code:claude-opus-5-5

This lets us see which tools are being used, and how much of our work is assisted by AI.

Have your AI tool add the trailer when it writes the commit, rather than adding it by hand, and check that it is there before you push.

2. Use only UIS enterprise-licensed tools

Only AI tools covered by a UIS enterprise licence can be used. UIS has enterprise licences for:

  • Microsoft 365, including Copilot Chat, only via the University tenancy.
  • Google Workspace, including Gemini and NotebookLM, only via the University tenancy.
  • Claude Code, only via the University tenancy.
  • GitLab Duo, only via the University's GitLab instance.

The current approved tools for project asset generation are:

  • Claude Code, only via the University tenancy.
  • GitLab Duo, only via the University's GitLab instance.

For project work, use these tools' official agents, which work from the repository's context and can run its tests and linters to check their output.

When the assets generated don't require project content, e.g. image generation, other UIS enterprise-licensed tools can be used.

Sign in to these services with your University account, so that the University's licence applies.

Under the enterprise contracts, our code and data are not used for model training, and the vendors make privacy and data protection commitments.

The following are explicitly not allowed:

  • local or self-hosted LLMs without approval from the Tech Lead Forum,
  • AI tools or extensions not licensed by UIS, and
  • free-tier or personal accounts for AI services, including AI features built into operating systems and apps when they run under a personal account, such as Apple Intelligence with a personal Apple Account.

Local models keep data on your machine, but bring their own risks: some model file formats can run code when they are loaded, and the runtimes that serve them are not vetted by UIS. Free-tier and personal accounts come with no enterprise contract, so there are no legal guarantees on how data is handled.

Note

The Tech Lead Forum reviews the approved tool list regularly. AI development tools change quickly and we will move to better ones as they appear, so expect to switch tools and models from time to time.

3. Human review required

Human review of all AI-generated or AI-assisted output is mandatory, and the submitter is fully responsible for its quality and correctness.

Specifically:

  • All AI-generated code must be reviewed before submitting a merge request.
  • All AI-generated documentation, images, or other content must be reviewed before publishing or sharing.
  • When an agent opens a merge request, the person who ran the agent is the submitter. They must review the changes before asking anyone else to.
  • An AI review, such as GitLab Duo's merge request review, does not replace human review and approval.

Submitting AI-generated work means you confirm that this review has been done.

4. Secrets and credentials

Never give AI agents access to real secrets or credentials. Treat any credential an agent can reach as disclosed.

What an agent can reach depends on how it runs. Without a sandbox, an agent on your machine can read your files, see your environment variables, use any session you are signed in to, and send data anywhere on the network. A sandbox narrows that, but only as far as it is configured to. Claude Code and GitLab Duo both offer sandboxes, but they can be turned off or fall back to running unsandboxed, and they do not always block reading files or environment variables by default. Check what your sandbox blocks before relying on it to protect your secrets.

An enterprise contract does not change this: it covers what the vendor does with our data, not what the agent does with a credential.

Personal data is covered in section 5.

4.1 Production secrets

A production secret is any credential, token or session that can read production data, read another production secret, or change production. Some credentials fall under this without looking like production secrets, for example a GitLab token whose owner can read a production project's CI/CD variables.

Hiding a credential's value from the agent does not make it safe. Docker Sandboxes, for example, can keep an API key outside the sandbox and add it to the agent's requests as they leave. The agent never sees the key, but it can still do everything the key allows, so a production key used this way still counts.

No production secret may be reachable by an agent, by any route:

  • No production secret in any environment variable, in any environment the agent runs in. This includes the developer's shell and shell profile (.bashrc, .zshrc), the editor or IDE process, any terminal the agent can spawn, CI jobs that run agents, and containers or devcontainers the agent can inspect or has a shell in.
  • No production secret in any file the agent can read. This includes .env and other secrets files in the working tree, kubeconfig files, service-account JSON keys, SSH private keys, and cloud CLI credential caches.
  • Agents must not be given access to 1Password or any other credential store or secret manager. This applies however the access is offered: an MCP server, a browser extension, a CLI such as op, an unlocked desktop app, or an already-authenticated session the agent could drive. An agent may read op:// secret references but must not resolve them, so it must not run op or any task that resolves them, such as poe up. An agent running that task brings up the same 1Password prompt you see every day, so never approve one you did not trigger yourself.
  • Agents must not inherit sessions that resolve to production. If your shell is authenticated to a production project, cluster, or account (for example via gcloud, kubectl, or a cloud CLI login), switching project or context is not enough: the credentials stay cached and the agent can switch back. Either revoke the session (for example gcloud auth revoke and gcloud auth application-default revoke) and remove production contexts before running an agent, or run the agent with a separate configuration directory (CLOUDSDK_CONFIG, KUBECONFIG) or in a sandbox that has never held them.

Secrets needed for local development should be kept in 1Password and referenced from the repository with op:// secret references, so the repository holds no secret values. Deployed services keep receiving secrets from the platform, such as Google Secret Manager.

Moving to 1Password secret references

Some repositories still keep secret values in environment variables or env files, such as the secrets.env file in our webapp boilerplate. Once migrated, that file holds only op:// references, which are not secrets. Running poe up brings up a 1Password prompt, and the values are only resolved once you approve it. The project's tooling must resolve them at run time without writing them to disk, for example with op run rather than op inject. Resolved values are still visible to anything that can inspect the running application or its containers, for example with docker inspect.

This note will be removed once all our services use 1Password secret references.

If an agent needs credentials in order to run something, such as the test suite, they must be fake/placeholder values, or credentials for an environment containing only synthetic or public data. These can stay in plain configuration, as the boilerplate already does for tests with pytest-env, so that agents can run tests without resolving any op:// reference.

4.2 Staging and development secrets

Staging and development secrets are not automatically safe. A non-production secret must be treated exactly like a production secret whenever it grants access to sensitive production data, or to a system shared with production.

The following must not be exposed to an agent:

  • Credentials for any development or staging environment whose database is restored or replicated from a production database holding personal data, confidential information, or secrets such as stored API tokens or password hashes. A copy of that data is as sensitive as the original, wherever it sits.
  • Credentials for external or third-party development or staging systems (payment sandboxes, email and SMS providers, identity providers, ticketing systems, and similar) where the account, tenancy, or data is shared with production, or where the system can act on the real world, for example by sending messages to real people.
  • Any credential where you are not certain what the data behind it contains. If in doubt, assume it is sensitive production data.

In practice, only credentials for environments containing synthetic or public data should be present in an agent's environment.

4.3 Practical measures

  • Keep secret values out of the working tree entirely. Commit 1Password op:// references in place of a secrets file (section 4.1). The only plain values in the repository should be fake ones, or credentials for environments containing only synthetic or public data.
  • Do not rely on a tool's context exclusion or file permission settings to protect a secrets file. Support varies between tools and modes, and an agent that can run commands may be able to read the file through a terminal anyway. These settings only reduce what gets sent as context by accident.
  • Run agents from a shell, profile, or container that has no production or production-derived credentials available to it.
  • Review what each MCP server and extension is granted before enabling it; an integration that can read a credential store is equivalent to handing the agent the credentials.
  • If a real secret is ever exposed to an agent, treat it as compromised: rotate it immediately and report it as an IT security incident.

4.4 Trusted MCP servers only

Only use trusted MCP servers, such as those published by a large organisation or an open source community that offers some assurances. Examples are the GitLab MCP server on our own GitLab instance, the official Playwright MCP and Google Chrome's MCP. Untrusted servers may return misleading or malicious content.

Browser MCP servers must use a dedicated browser profile, never your everyday or personal one. Treat every session that profile is signed in to as access you have given the agent: sign in only to what the task needs, and sign out of anything it no longer needs. Section 4.1 still applies, so never sign that profile in to 1Password or to anything with production access.

Agents can be manipulated by text embedded in what they read, such as an MCP server's response or a web page. An agent that reads untrusted content and also holds credentials can be made to exfiltrate them.

5. Personal data

Personal data is any information that identifies a living person, directly or indirectly.

The University's guidance on using GenAI applies in full in this area.

Policy review

This policy is owned by the Tech Lead Forum, which reviews and updates it as AI tooling evolves. Send feedback and suggestions to the Tech Lead Forum.

Last reviewed: October 2026.