Continuous assurance: proving it before it ships, and after

The other layers describe the controls the system needs. This one asks what must be proven before a release is allowed to run, and re-proven whenever it changes, to earn the right to ship it. It is the difference between hoping an agent is safe and having evidence that it is.

There are seven controls here. I will group them by what they prove: that you tried to break it, that the pipeline is a gate and not a suggestion, that the supply chain is trustworthy down to the model's weights, and that you understand what the model itself can do.

Try to break it before anyone else does (AS-01, AS-04)

Red-team it before launch (AS-01). Try hard to break the agent yourself before anyone else can. Resistance to goal hijack and to multi-turn drift (the agent slowly being steered off course over a long conversation) has to be measured, not assumed, because an agent that looks safe in a demo can fold under a determined adversary. So run adversarial red-team suites and agentic evaluation benchmarks covering hijack, tool misuse, and exfiltration, and crucially include multi-turn scenarios, not single prompts, because the drift only shows up over a session. The tooling for this has matured fast: open benchmarks like AgentDojo (hundreds of injection cases) and the OWASP FinBot capture-the-flag exercise the abuse paths, and automated red-teaming harnesses such as Microsoft's PyRIT can drive the attacks for you instead of relying on hand-written prompts. The technical output you want is an attack-success-rate measured against a launch threshold. Functionally: launch is a number you clear, not a vibe you feel.

Pay outsiders to find what you missed (AS-04). Pay outside researchers to find the abuse paths your own testing missed. A safety-focused bug-bounty program, scoped explicitly to agentic abuse, prompt-injection hijacks, data exfiltration, harmful autonomous actions, brings adversarial attention you cannot generate in-house. The "scoped explicitly" part matters: a bounty written only for classic application security will have researchers reporting web bugs while the agent-abuse paths go unhunted. Feed every validated report back into your red-team scenarios so the same hole is caught automatically next time.

Operational profile. Enforcement points, AS-01: a pre-deployment red-team / eval harness gated on a launch threshold (an attack-success-rate you clear). AS-04: an external bug-bounty program scoped explicitly to agentic abuse, feeding back into the AS-01 suite.

Make the pipeline a gate, not a suggestion (AS-02, AS-03)

Scan skills and manifests in CI (AS-02). Automatically scan every plug-in and its manifest for problems before it ships. CI here is continuous integration, the automated pipeline that builds and checks code on every change. Run SAST (static application security testing, which analyzes code for vulnerabilities without running it) and manifest scanning on every skill change, review dependencies for known-vulnerable components, and, the load-bearing word, fail the build on high-severity findings. A scanner that runs but does not block the merge is theater. Functionally: the gate has to be able to say no.

Re-test on every release (AS-03). Re-test for safety on every release, because agent behavior drifts over time. A one-time pre-launch audit does not satisfy a runtime-risk requirement, because emergent behavior changes the risk profile run to run, and a model or prompt update can quietly regress safety. So run the adversarial evaluation suite as a gate on every deployment, and block any release that regresses against the safety baseline. This maps directly onto the EU AI Act's Article 9, which frames risk management as a continuous duty rather than a one-time sign-off. Functionally: safety is a thing you keep proving, not a box you check once.

Operational profile. Enforcement point, AS-02, AS-03: the CI/CD pipeline, fail-closed on the build. AS-02 runs SAST and manifest scanning on every skill change; AS-03 runs the adversarial evaluation suite as a release gate on every deployment. A scan that does not block the merge, or an eval that does not block the release, is theater.

Trust the supply chain down to the weights (AS-06, AS-07)

These two close holes that signing alone leaves open, and they are where assurance is moving fastest.

Verify the model's own provenance (AS-06). Make sure the model itself, and the data it learned from, is genuine and unaltered, not just the plug-ins. Signing your skills protects the add-ons, but a poisoned or swapped base model bypasses all of it, because a backdoor can live in the weights, not the manifest. (Weights are the learned numbers that are the model.) So sign and verify model weights before load, using emerging tooling like the OpenSSF Model Signing project and Sigstore's model-transparency work, and keep an ML-BOM, a machine-learning bill of materials, the itemized list of what went into the model, including its training data's provenance. Make verification a hard gate that refuses an unverified or swapped model. Be precise about what this buys, though: a signature proves the weights you loaded are the ones that were signed (artifact integrity); it does not prove the training data was genuine or faithfully represented (lineage), which needs separate provenance attestations and is a weaker, newer guarantee. This is a fast-moving area: CISA's SBOM-for-AI work is converging on a minimum set of things such a bill of materials should record, from model components to dataset lineage to the guardrails in place.

Verify a skill does what it says (AS-07). Check that a plug-in actually does what its description says, not just that it is signed and clean. This is the gap between "genuine" and "honest." Signing proves a skill is unaltered, and scanning catches known-bad patterns, but neither proves the skill does what it declares. The numbers here are striking: in one study's corpus of 49,943 skills, roughly 80% deviated from their declared behavior, almost 19% from adversarial intent, and about 5% carried multi-stage attack chains hidden inside legitimate-looking skills, a skill that says "read a file" but actually reads the file and exfiltrates credentials or opens a shell. (One corpus, not the whole ecosystem, but a loud signal.) So extract what a skill really does, its actual filesystem, credential, shell, and network access, through automated static analysis (AST parsing of the plug-in code before it loads), and compare that against its declared capabilities over a shared taxonomy. Anything whose real capabilities exceed or contradict its declaration gets blocked. Functionally: you are checking the handwriting against the label, and re-checking on every update.

Operational profile. Enforcement points, AS-06: the artifact / model registry at build time, where weight signing (Sigstore / OpenSSF Model Signing) and the ML-BOM live, a separate layer from the application's manifest checks. AS-07: a behavioral static-analysis gate (AST parsing of the skill) at load time, blocking anything whose real capabilities exceed its declaration.

Understand the model itself (AS-05)

Check whether a powerful new model can find and exploit vulnerabilities before you ship it. A model approaching expert-human skill at finding and exploiting vulnerabilities is a release-gating risk in its own right, independent of any particular deployment, because it changes what monitoring, access, and control a release needs even when the app on top looks low-risk. The frontier labs have converged on studying this before release, through pre-release red-teaming and control evaluations, with staged release tied to defined risk thresholds, OpenAI's Preparedness Framework is one published example, and Anthropic frames its Project Glasswing defensively, studying capability in order to secure critical software. The posture underneath it is the same one the runtime layer takes: treat the agent as a potential insider threat and do not assume alignment removes the need to check.

This layer splits by role, and it is worth saying plainly. Model producers run the frontier-capability evaluations, sign the weights, and attest to training lineage. Most enterprises consuming a hosted model cannot reproduce any of that; what they can do is require the provider's attestations, pin approved model versions to their own release gate, test the deployed application, and tighten runtime controls when the evidence is incomplete.

Operational profile (AS-05). Enforcement point: the model producer's frontier-capability evaluation, run before release against defined risk thresholds. For consumers, the enforceable surface is a version-pinning release gate plus the provider's published attestations.

Where this layer is heading

The clear trend is from one-time to continuous, and from the wrapper to the weights. Assurance used to mean a pre-launch test; it is becoming a gate that fires on every release, mapped to regulation that treats risk management as ongoing. And the trust boundary is moving deeper, from signing the plug-ins, to verifying the model's weights and training data, to checking that a component honestly does what it claims. The supply-chain tooling for AI, model signing, ML-BOMs, behavioral verification, is young but moving quickly, and building to it now is building for where audits are going. If this is your emptiest layer, start with a blocking CI gate (AS-02) and a real pre-launch red-team with a threshold (AS-01); they catch the most before anything reaches production.

The handoff

Assurance proves the agent before it ships, then hands its results to runtime, where they quietly decay. The invariant that must survive: a release-test result is only valid for the exact thing tested. The evidence that must cross is the binding between what was tested (model version, prompt hash, tool manifest, eval baseline) and what is running live, so a responder can ask "was this configuration actually tested?" and get an answer. Who owns the failure when a prompt or tool changes after the gate and silently invalidates the assurance? The concrete test: you pass a red-team gate at launch, then a tool's description updates a week later, is the green checkmark still true, and does anyone know it is not?

You can filter the full Apeiris Security domain to just these seven controls, with the standards, the tools that build them, and the validation steps, at apeiris.ai.

Sources

• AgentDojo · OWASP FinBot CTF · Microsoft PyRIT
• OpenAI, Preparedness Framework v2 · EU AI Act Article 9 (continuous risk management)
• OpenSSF Model Signing / Sigstore model-transparency · CISA, SBOM for AI: Minimum Elements
• Wu, Li & Liu, Behavioral Integrity Verification for AI Agent Skills (arXiv 2605.11770) · Anthropic, Project Glasswing