Extending Foundation Model Capabilities: Engineering Practices for Safety and Control

Capability Gains Are First an Engineering Problem

In public discussions, next-generation general-purpose models are often described as being able to “work continuously for longer”: decomposing tasks, calling tools, running multiple sub-agents in parallel, and consolidating the results into runnable artifacts. For engineering teams, the most important question is not how impressive a particular demonstration looks, but how these capabilities change the cost structure of software delivery.

Exploration work that previously required weeks of manual decomposition may now be compressed into days in a controlled environment. At the same time, errors can spread just as quickly. Incorrect interface assumptions, unreviewed system calls, and unauthorized data access can all be amplified by an automated workflow.

When evaluating frontier models, teams should therefore ask three questions:

1. Can the task be decomposed and replayed?
2. Can intermediate artifacts be verified?
3. Are permissions minimized by default when something fails?

Comparing only generation speed or unit cost overlooks the main risks that appear after deployment.

What Dual-Channel Access Means

The industry is gradually adopting a layered access model. Public interfaces typically restrict high-risk capabilities by default. More powerful professional assistance may be made available to qualified cybersecurity and life sciences organizations under contractual, auditing, and use restrictions. Both channels can share the same underlying model; the primary difference lies in the policy layer, not in how “intelligent” the model is.

Public channels generally block penetration-testing guidance, exploit generation, and many research requests that could contribute to biological harm. Professional access does not remove boundaries. Instead, it changes the boundary from blanket refusal to traceable authorization. The requesting organization, project scope, data destination, personnel permissions, and result-review process should all be defined in advance.

Organizations building similar internal systems should not automatically treat “internal employee” as equivalent to “authorized researcher.”

In practice, four categories of controls should be established:

• Identity and purpose binding: Map the caller, project identifier, and data classification to one another.
• Tool allowlists: Expose only the tools that are necessary, such as read-only retrieval, sandboxed compilation, and static analysis.
• Output classification: Send executable patches, system configurations, and experimental plans for human review by default.
• End-to-end traceability: Store prompts, tool parameters, model outputs, and approval decisions in logs that cannot be casually altered.

Organizing Long-Running Agents

Statements such as “coordinating many sub-agents to build complex software” should be understood as an orchestration problem, not magic. A maintainable system should include at least a planner, executor, reviewer, and merger.

The planner produces only a task graph. Executors modify code or run tests in isolated environments. Reviewers compare results against acceptance criteria and reject branches that do not qualify. The merger resolves conflicts while preserving the associated decisions.

A task specification can be intentionally simple. The important part is constraint-setting rather than elegant wording:

Goal: Build a bootable minimal system prototype in an isolated virtual machine
Constraints: Do not access the production network; do not write to the host filesystem
Acceptance: Boot logs, critical service health checks, and failure rollback
Permissions: Read-only dependency sources and a local build cache only

The main resources consumed by this type of workflow are context and review capacity. As the number of sub-agents increases, the bottleneck is often not whether the model can write code, but whether the controller can detect duplicated work, recursive calls, and quietly expanding permissions.

Practical controls include:

• Set step and time limits for every subtask.
• Require each agent to report what it changed, why it changed it, and how the change was verified.
• Run the same regression suite before merging instead of relying only on the model’s own summary.

Building a bootable system prototype from scratch is useful as a capability probe, but it should not be treated as a production operating-system design. The probe should examine whether the boot process is repeatable, whether the driver and user-space boundaries are clear, and whether failures can be located. Production systems must also address hardware variation, long-term maintenance, supply-chain security, and security updates. A single demonstration cannot replace that work.

Turning “Looks Correct” Into “Can Be Checked”

Formal proofs differ from ordinary code generation because the conclusion must be accepted by a proof checker rather than merely judged correct by the model. A practical use case is to express a conjecture or critical property as a statement that a proof assistant can verify, then assign multiple agents to fill in lemmas, identify gaps, and simplify the proof.

A speed improvement that comes only from skipping verification has no engineering value.

A general workflow is:

1. A human clearly defines the proposition to be proved and the permitted axioms.
2. The system generates a proof draft and submits it automatically to the proof checker.
3. Failure information is fed back without modification; the model must not claim in natural language that the statement has been proved.
4. Only the version accepted by the proof checker is archived, together with the versions of the libraries used.

The same principle applies to ordinary software. Unit tests, type checks, static analysis, and diff reviews are all control points that trade generation speed for confidence. Without them, increasing the number of parallel agents makes it easier for a repository to accumulate changes that no one can explain.

Where Research Assistance Should Stop

Models can help organize literature leads, propose testable hypotheses, draft computational workflows, and summarize negative results. In life sciences, however, computational structural predictions must be kept separate from materials and procedures that can directly enter an experiment. Even a seemingly high hit rate for structure prediction produces candidates, not validated results. It cannot replace experimental measurement and should not be turned into actionable procedures for acquisition, modification, or delivery.

The same principle applies to cybersecurity. Models can explain the impact of vulnerability classes, help write defensive detection rules, and assist with pattern identification during code audits. They should not provide exploit steps, payloads, or evasion techniques that could be used for unauthorized testing.

A decline in sandbox-escape attempts may indicate stricter policies, but it does not mean that real-world risk is now predictable. Tool combinations not covered by evaluation sets, indirect instructions in long contexts, and multi-turn requests split into smaller parts may still bypass single-turn tests.

Enterprises should acknowledge the limits of evaluation. Alignment scores can be part of a release gate, but they are not sufficient as the only proof of safety. After deployment, teams must continue monitoring whether refusals remain consistent, whether unauthorized tool calls are blocked, and whether users are attempting to evade policies through decomposed requests.

Anti-Distillation and Interface-Level Protection

The more capable a system becomes, the more attractive its interface is for systematically extracting behavior. Common protections include rate limiting, anomalous-call detection, output perturbation, and access controls for high-value traces. The goal is to reduce the amount of useful training signal that can be collected at scale.

The appropriate ratios and thresholds depend on the attacker’s budget and the interface design. Marketing claims should not be treated as security guarantees. More reliable practices include keeping high-risk capabilities off public interfaces, avoiding logs that retain sensitive prompts in recoverable form, and separating internal evaluation sets from production traffic.

An Enterprise Deployment Checklist

When using general-purpose capabilities in the cloud, organizations should prioritize architectural categories rather than tying their design to a particular marketing name:

• Container platforms for build isolation
• Object storage for immutable artifacts
• Message queues for decoupling subtasks
• Logging, monitoring, and alerting for detecting anomalous calls

General cloud services such as Baidu AI Cloud can host these components, but the responsibility boundary remains with the user. Data classification, permission approval, and result review cannot be outsourced to default console settings.

Before production release, verify each of the following:

• High-risk cybersecurity and biological requests are denied by default. Any exception has a documented scope and expiration date.
• Agents can call only allowlisted tools, and production credentials never enter the prompt context.
• Every automated change can be rolled back, and merges require human review or an equivalent mandatory check.
• A complete audit trail is retained, and adversarial samples are replayed regularly to detect policy degradation.
• Capability boundaries are clearly communicated externally. Prototype demonstrations must not be presented as validated production results.

Conclusion

The value of frontier models lies in shortening exploration cycles, and the risks come from the same source. By placing dual-channel permissions, long-running orchestration, verifiable proofs, and continuous evaluation into one delivery pipeline, teams can benefit from speed without being controlled by it.

Demonstrations can inspire architectural design. Acceptance, however, should still rely on isolated environments, proof checkers, and audit records.