When open-source agent infrastructure is the responsible choice

Open source can be the responsible architecture choice for an agentic system. It can also be an attractive way to inherit a complex supply chain with no one accountable for operating it. The difference is not ideology. It is whether openness produces control that the organisation can actually exercise.

Agent infrastructure spans more than a model: orchestration, tool gateways, identity integration, memory, evaluation, observability, sandboxes and user interfaces. Each component may be open, source-available, open-weight, commercially licensed or managed. A responsible decision names the exact layer, the rights obtained, the evidence available and the operational duty accepted.

Ask what is open before asking whether open is better

“Open-source AI” is not a precise description of every downloadable model. The Open Source AI Definition 1.0 frames openness around the freedoms to use, study, modify and share an AI system, with access to the preferred form for making modifications. The OECD’s primer on AI openness describes openness as a spectrum across code, weights, documentation and data, each of which can be available under different terms.

For each proposed component, record:

• source code available and licence;
• model weights available and licence;
• training or adaptation data information;
• build, training and evaluation procedures;
• dependency and software bill of materials;
• security advisories and update history;
• trademark, acceptable-use or field-of-use restrictions; and
• rights to modify, redistribute, host and terminate use.

A repository being public does not answer these questions. Nor does “free to download.” Legal review should resolve licence obligations; architecture review should determine whether the available materials are sufficient to inspect, reproduce, modify and operate the component for the intended use.

Openness is valuable when it changes a real constraint

Choose an open component for a stated operating reason, not as a general virtue. Four reasons can be material.

Inspection. Security and engineering teams can examine code paths, tool semantics, default permissions and telemetry. This is valuable when a component sits on a consequential action path and provider assertions are insufficient.

Modification. The organisation can add policy enforcement, remove unwanted connections, adapt interfaces or fix defects without waiting for a vendor roadmap.

Deployment control. Workloads can run in a defined environment to meet latency, connectivity or data-residency constraints. The organisation controls when versions change.

Portability and exit. Open formats and replaceable components can reduce dependence on one supplier, especially when prompts, evaluations, traces and tool contracts remain portable.

The Mozilla framework for openness in foundation models emphasizes that openness varies across the stack. This helps avoid an all-or-nothing choice: an organisation might use an open orchestration layer with a managed model, or an open-weight model behind a proprietary safety gateway. Evaluate the actual combination.

The responsible choice depends on operating capacity

Open source transfers options and responsibilities. A self-hosted component needs an owner for deployment hardening, identity, capacity, monitoring, patching, incident response and lifecycle. If the team cannot perform those functions, theoretical control may become practical neglect.

Use a readiness test:

Responsibility	Evidence before adoption
Provenance	Maintained origin, signed artefacts where available, pinned dependencies
Security	Threat model, hardening baseline, vulnerability intake and patch target
Reliability	Load, failure, recovery and upgrade tests in the intended environment
Model governance	Version, evaluation, data handling and known-use boundaries
Operations	Named on-call path, observability, backup, rollback and decommissioning
Community dependency	Maintainer health, release cadence, governance and fork strategy

CISA’s guidance for organisations using open-source software highlights asset inventory, vulnerability management, patching, authentication and authorisation, and support for the ecosystems relied upon (CISA and partner recommendations). Those fundamentals apply directly to agent infrastructure, where a vulnerable connector or tool server may also hold delegated credentials.

Inspectability is not proof of safety

Open code enables examination; it does not establish that examination occurred or that a deployed build matches the code. Security evidence should connect source, build artefact, configuration and running version.

For a tool gateway or orchestration framework, review:

• default network exposure and credential storage;
• authentication and tenant isolation;
• how tool descriptions and outputs enter model context;
• permission and policy enforcement outside the model;
• sandbox boundaries for code or local processes;
• logging of sensitive prompts, data and secrets;
• plugin and package installation paths; and
• update authenticity, rollback and unsupported versions.

The international Guidelines for secure AI system development call for secure-by-design choices across development, deployment and operation, including supply-chain security, least privilege, monitoring and responsible release. Those controls do not appear automatically when the licence is open.

An internal fork deserves particular caution. A security patch that never reaches the fork can erase the benefit of local modification. Define which changes will remain as configuration, which will be contributed upstream and how divergence will be measured.

Open models require a separate risk decision

An open orchestration library and an open-weight foundation model create different questions. A library can usually be patched and rebuilt; released model weights encode behaviour that is harder to inspect or repair. Hosting weights locally may improve data control but can remove provider safeguards and make the organisation responsible for abuse prevention, model access and evaluation.

The OECD notes both benefits—competition, research, transparency and local adaptation—and risks such as misuse, privacy, intellectual property concerns and uncontrolled proliferation. The relevant question for an enterprise deployer is narrower: does local control materially improve this workflow, and can the organisation manage the resulting model and infrastructure risks?

Test the exact model build under the exact serving configuration. Quantisation, fine-tuning, system instructions and inference settings can change behaviour. Preserve the model hash, licence, source, evaluation record and deployment limits in the release manifest.

Compare complete operating models

Do not compare a licence fee for a managed service with a download price of zero. Compare total operating models:

• infrastructure, energy and capacity engineering;
• integration, security review and compliance work;
• evaluation and model updates;
• vulnerability monitoring and patching;
• operational staffing and incident response;
• portability and switching costs; and
• failure exposure and recovery time.

A managed provider may offer better resilience and response than a small internal team. An open component may offer stronger inspectability, data locality and exit options than a closed service. Neither conclusion follows from the category alone.

Run a proof with predetermined thresholds. Require the open option to demonstrate the claimed advantage—such as local latency, reduced data transfer, faster control modification or a successful provider-exit exercise—while meeting quality, security and operability requirements. Preserve failed results as evidence; enthusiasm is not a reason to move the threshold.

Make ownership the deciding test

An open-source choice is responsible when all of the following are true:

• the exact openness and licence are understood;
• openness solves an important architecture or governance constraint;
• the component can meet task-specific quality and security thresholds;
• the organisation has named owners and funded operating capacity;
• provenance, build and deployed version are traceable;
• updates, vulnerabilities and upstream health will be monitored; and
• an exit, replacement or decommissioning path has been tested.

If those conditions are absent, a managed service with strong contractual, technical and portability controls may be more responsible. If provider opacity or data handling prevents the necessary evidence, an open or self-hosted option may be the only acceptable path.

Open source offers the ability to take responsibility. The architecture decision is credible only when the organisation is prepared to take it.