Reported operating use · AI infrastructure and security
AI agent containment testing: OpenAI example
OpenAI reports using agent teams to test containment in copies of its research infrastructure. Automated triage grouped candidate findings, security and infrastructure teams reproduced them and verified configuration repairs, and monitoring was designed to pause runs on out-of-scope activity.
Test agent containment and verify security repairs
OpenAI
Reported internal security work in isolated copies of research infrastructure; published 23 October 2026.
A published third-party example, not a Nuvepro customer case or evidence of a partnership.
The workflow at a glance
Test containment and verify repairs
Illustrative summary of the published account
Reported work components. Their arrangement does not imply a fixed execution order or simultaneous work.
- Test scope
Copies of research infrastructure
OpenAI reports agent teams testing containment in isolated copies.
- Triage and repair
Grouped candidate findings
Security and infrastructure teams reproduce findings and verify configuration repairs.
- Oversight
Monitoring and cloud-partner supervision
Programmatic checks are designed to pause out-of-scope activity; continued testing remains necessary.
What the source reports
OpenAI reports using agent teams to test containment in copies of its research infrastructure. Automated triage grouped candidate findings; security and infrastructure teams reproduced findings and verified configuration repairs. Cloud partners helped supervise the experiments. The account describes monitoring and programmatic checks designed to pause runs on out-of-scope activity and treats continued testing as necessary after repairs.
Reported technology: OpenAI internal models and security teams. Scope and outcomes are source-reported.
What the enterprise environment would need
The following is a proposed project design for an enterprise doing similar work. Published details are marked; the remaining systems, data and scenarios would be agreed for your project.
Proposed practice environment
Rehearse a permission-boundary finding
Illustrative project design to scope with your enterprise.
- 1 · Set up the environment
Isolated authorized application copy
Use synthetic records/credentials and a written permitted-test list; no customer production access.
- 2 · Preparation and agent contributions
Agent records a candidate boundary failure
Keep attempt logs, configurations, unsuccessful tests and repair proposals.
- 3 · Independent checks
Separate engineer reproduces and rechecks
Compare permission matrix before and after repair; test that out-of-scope attempts stop.
- 4 · People decide acceptance
Security owner accepts evidence
Decide whether the reproducible repair is sufficient within the agreed scope.
A reviewable evidence package
A finding register, repair diff and repeatable permission-check results.
If a check fails → withhold acceptance.
A finding cannot be reproduced or the repair broadens permissions. Keep it unresolved and route to the security owner.
Failure or owner rejection returns to review
- Hold
- → 2 · Revise work
- → 3 · Rerun independent checks
- → 4 · Owner review
Operating boundary. No production targets or expanded access; testing remains within written authorization.
- Authorized test scope
- Proposed: an isolated copy of an agreed application environment, synthetic records and credentials, and a written list of permitted tests. No access to customer production systems.
- People and decisions
- Proposed: a security owner approves scope, engineers reproduce candidate findings, and a separate reviewer decides whether repair evidence is sufficient.
- Records and outputs
- Proposed: versioned configurations, attempt logs, a finding register, repair diffs and repeatable checks. Preserve unsuccessful attempts and disputed findings.
A proposed simulation
An illustrative practice design derived from this work, not an executed assessment.
Proposed: inspect a supplied test environment, record a permission-boundary finding and prepare a repair for engineer review.
Review gate: A separate reviewer can reproduce the finding and confirm the repair against the agreed permission matrix. The security owner decides acceptance.
Challenge the result: A candidate finding cannot be reproduced, or its proposed repair grants broader permissions. Keep it unresolved and route it to the security owner.
What needs checking
- Proposed: compare allowed and denied actions against an owner-approved permission matrix before and after each repair.
- Proposed: independently reproduce a reported boundary failure, then verify the repair without expanding access.
- Proposed: test that an out-of-scope attempt stops the run and produces an actionable record for the responsible engineer.
Review environment fidelity, human capability and agent performance separately. The enterprise’s accountable owners decide acceptance of the shared workflow and any operating use.
How an enterprise could build similar work
A proposed build order for an enterprise doing similar work, written by Nuvepro from the published account and our interpretation of the environment and checks above. It is not how OpenAI built or operates this work.
- Define the authorised test scopeThis is a proposed design for a similar project, not OpenAI's infrastructure. Use an isolated copy of an agreed application environment, synthetic records and credentials, and a written list of permitted tests, with no access to customer production systems.
- Assign people and decisionsA security owner approves scope, engineers reproduce candidate findings, and a separate reviewer decides whether the repair evidence is sufficient. Keeping these roles apart stops the person proposing a repair from also accepting it.
- Record attempts and outputsKeep versioned configurations, attempt logs, a finding register, repair diffs and repeatable checks. Preserve unsuccessful attempts and disputed findings, so the record shows what was tried and not only what worked.
- Set a permission matrixHave the owner approve a permission matrix of allowed and denied actions. Compare actions against it before and after each repair, so a repair is judged against agreed limits and not against the agent's own report.
- Test reproduction and stoppingInspect the supplied environment, record a permission-boundary finding and prepare a repair for engineer review. Independently reproduce the failure, verify the repair without expanding access, and test that an out-of-scope attempt stops the run.
- Run the failure testInclude a finding that cannot be reproduced, or a repair that grants broader permissions. Keep it unresolved and route it to the security owner, who decides acceptance only after the separate reviewer confirms against the matrix.
Your systems, data, rules and accountable owners decide the real project. Agree acceptance criteria, escalation owners and operating responsibility with the people accountable for the work before anything runs on live records. Treat the first run as a rehearsal on test records: compare the draft output with an independently prepared answer, and record what the people reviewing it change.
Questions about this example
- What does OpenAI use AI for in containment testing?
- OpenAI reports using agent teams to test containment in copies of its research infrastructure, with automated triage grouping candidate findings. Cloud partners helped supervise the experiments. The account treats continued testing as necessary after repairs are made.
- Who checks the findings in OpenAI's containment testing?
- Security and infrastructure teams reproduced findings and verified configuration repairs. The account describes monitoring and programmatic checks designed to pause runs on out-of-scope activity. Cloud partners helped supervise the experiments, so review was not left to the agents alone.
- How strong is the evidence for this OpenAI example?
- The evidence class is reported use: an operator account of internal work, published on 23 October 2026. It is not an independent security certification or a generally available service, and it does not establish the safety of another enterprise environment.
- What would an enterprise need to build something similar?
- This is Nuvepro's proposed design, not a copy of OpenAI infrastructure. It would use an isolated copy of an agreed environment, synthetic records and credentials, a written list of permitted tests, and a separate reviewer who reproduces each finding and repair.
Shape this around your enterprise
Bring a similar workflow and the people responsible for it. Together, define the records and systems to use, the result your team will build or configure, and how its owners will check it. Nuvepro scopes the simulation, environment and preparation. Agree any existing-agent evaluation, implementation assistance and production responsibilities separately.
Sources and limitations
Curation review: . This is the date this source example was reviewed, separate from source publication dates.
- This is an operator account, not an independent security certification or a generally available service.
- The report concerns internal research infrastructure; it does not establish the safety of another enterprise environment.
- The proposed project is not a replica of OpenAI infrastructure or an executed Nuvepro assessment.
- Securing our frontier model training environmentSource publication: 2026-10-23