Animus/ Blog
runtime ↗animus.team ↗github
← All posts
FIELD NOTES · 8 min read · The Animus Team

Why Plugin Signing Matters for AI Devtools and Agent Orchestrators

AI devtools are crossing a line that ordinary extensions rarely crossed. They do not just color syntax or format files. Agent orchestrators can install plugins, run binaries, invoke terminals, read task data, touch real repositories, and hand work to autonomous agents. If we want developers and platform teams to trust that kind of power, plugin signing cannot be an afterthought. It has to be part of the extension model from day one.

The plugin boundary is a supply-chain boundary

A plugin system for an agent orchestrator is not a theme marketplace. It is a path for third-party code to run close to source code, credentials, task trackers, build systems, and local developer workflows.

VS Code's Workspace Trust documentation is useful because it states the risk plainly. In Restricted Mode, VS Code disables or limits AI agents, terminal access, tasks, debugging, workspace settings, and extensions until a workspace is trusted. It also warns that AI agents can act on the user's behalf by changing code, running terminal commands, and making web requests. Most extensions run code on the user's behalf too, and could potentially do harm.

That is the right mental model for agent orchestration security. Animus, for example, is local-first and plugin-first. Providers, subject backends, triggers, transports, web UI, and log storage can all ship as independent animus-* plugins discovered by the daemon and routed through CLI, MCP, or web control surfaces.

That architecture is powerful. It lets a team connect the orchestrator to different agents, task systems, event sources, and interfaces. It also means a malicious provider plugin or subject backend is not just an inconvenience. It can sit in the path between the orchestrator, the repository, task data, credentials, and autonomous execution.

The safe question is not, "Can we install plugins?" The safe question is, "What must be true before this binary is allowed to run here?"

Checksums tell you what you got. Signatures tell you who it came from.

Every serious plugin ecosystem needs integrity checks. SHA256 verification and lockfiles are table stakes.

OWASP's CI/CD Dependency Chain Abuse guidance describes the core failure mode: dependency systems can cause developer workstations or build servers to fetch and execute malicious code. The outcomes can include credential theft and lateral movement. OWASP recommends checksum verification, signature verification, avoiding unconstrained latest, and locking to pre-vetted versions or ranges.

Animus follows that shape. A committed animus.toml can declare kernel, plugins, and packs. animus install resolves that manifest into .animus/plugins.lock. animus install --locked reproduces the lock exactly for CI and containers.

That matters because it reduces drift. A team can review the intended plugin set and reproduce it elsewhere.

But a checksum alone does not prove who produced the binary. Animus' plugin-signing design makes this distinction explicit: a SHA256 sidecar can prove the downloaded bytes were not corrupted in transit, but it does not prove publisher authenticity. If a release token or maintainer account is compromised, an attacker can publish a malicious binary with a matching checksum under the expected name.

This is the key security distinction for AI devtools:

  • A lockfile says, "Use this version and digest."
  • A checksum says, "These bytes match the expected digest."
  • A signature says, "These bytes were signed by the expected identity or workflow."

Agent orchestrators need all three.

Sigstore and cosign make signing practical

Plugin signing fails if it requires every plugin author to become a full-time key-management team. That is why Sigstore and cosign are a good fit for AI devtool ecosystems.

Sigstore is designed for signing and verifying release files, container images, binaries, SBOMs, and other software artifacts. It uses ephemeral signing keys and records signing events in a tamper-resistant public log. Sigstore also calls out the risks that matter for plugin marketplaces, including typosquatting, compromised hosting sites, and post-publication tampering.

Cosign's keyless model lowers the operational burden. Instead of managing long-lived signing keys, keyless signing associates signatures with identities. Fulcio issues short-lived certificates that bind an ephemeral key to an OpenID Connect identity, and Rekor logs signing events in a transparency log.

Animus' plugin-signing design uses that pattern for GitHub Actions releases. The release runner receives an OIDC token. Cosign creates an ephemeral keypair. Fulcio issues a short-lived certificate that embeds the workflow identity. Cosign signs the binary digest. A .bundle containing the signature, certificate, and Rekor proof is uploaded next to the release asset.

That is the right level of friction. Plugin authors can sign in release automation without storing long-lived secrets, and users can verify that an artifact came from the repository or workflow they intended to trust.

Safe extension lanes beat arbitrary local access

The goal is not to make extension ecosystems painful. The goal is to make the safe path the obvious path.

Animus' signing design shows what that can look like in practice:

  • Verify signatures when a .bundle is present.
  • Offer --require-signature so strict environments can refuse unsigned plugins or failed verification.
  • Keep --skip-signature as an explicit escape hatch for local or air-gapped development.
  • Check certificate identity against the GitHub repository the user installed from, using the GitHub Actions OIDC issuer.
  • Let organizations pin acceptable signers and publishers with trusted-signers.yaml.
  • Check that a plugin manifest name matches the expected repository shape, which helps catch near-name typosquat attempts.
  • Prevent a third-party provider from shadowing reserved first-party routes such as claude, codex, gemini, opencode, or oai unless explicitly allowed.
  • Prompt on first-time installs from unknown GitHub owners, while treating that as trust on first use rather than a replacement for signatures.

This is what a safe extension lane looks like: discoverable plugins, deterministic lockfiles, digest checks, manifest validation, publisher identity, and policy controls.

The unsafe alternative is to let arbitrary local binaries become part of the agent loop with little more than a name and a URL. In an ordinary app, that is risky. In an agent orchestrator, it is worse because the plugin can be adjacent to autonomous action. It may influence which agent runs, which task is selected, what context is exposed, which commands are launched, or which repository data is read.

Signing is not bureaucracy in that world. It is the mechanism that lets a platform say, "This binary came from the publisher or workflow you intended, matches the locked digest, declares the manifest you expected, and is allowed by your policy."

That is how autonomous tooling earns permission to operate.

Start with signatures, then add provenance

Signing is not the end of supply-chain security. It is the beginning of a credible control plane.

SLSA's requirements explain the next layer: provenance should identify the output package by cryptographic digest and describe how it was produced. Consumers should be able to validate provenance authenticity so they can verify integrity and identify the build platform and entities they need to trust. SLSA also recommends signing approaches that improve detection and remediation of key compromise, including transparency logs or time-stamping services.

Animus' current signing design is appropriately scoped. It treats "proving the source code matches the binary" as a non-goal and calls reproducible builds a separate concern. That is a reasonable sequence for a young ecosystem. First, bind artifacts to identities. Then add build provenance and attestations as the ecosystem matures.

Do not wait for the perfect end state before adding the first control. A plugin ecosystem without signing will eventually have to retrofit trust after users, workflows, and automation already depend on it. That is harder than making signing part of the first install story.

What devtool builders should do now

If you are building AI devtools, agent orchestration, or any plugin-driven local automation, treat plugin installation as a privileged supply-chain event.

A practical baseline looks like this:

  1. Use lockfiles by default. Keep plugin versions and digests reproducible across developer machines, CI, and containers.
  2. Verify SHA256 digests. Integrity checks should be mandatory, not a power-user option.
  3. Add Sigstore/cosign signing early. Bind plugin artifacts to publisher or workflow identities before the ecosystem grows.
  4. Make strict mode easy. Platform teams should be able to require signatures and trusted signers in production, CI, and managed environments.
  5. Validate manifests. Plugin identity, capability declarations, and reserved names should be checked at install time.
  6. Keep escape hatches explicit. Local development and air-gapped workflows may need bypasses, but those bypasses should be visible and intentional.
  7. Plan for provenance. Signatures answer who signed the artifact. Provenance helps explain how it was built.

AI devtools security will not be won by asking users to trust every extension less. It will be won by giving teams a way to trust specific artifacts for specific reasons.

Plugin signing gives agent orchestrators that language of trust. It turns "download and run this binary near my repository" into a policy decision a team can review, reproduce, and enforce.

For autonomous tooling, that difference matters.

Sources