Your AI Agents Ship Unsigned. Here’s the Security Gap.

Key takeaway: AI agents are not just code or models; they are dynamic assemblies of prompts, tool grants, model bindings, and third-party integrations. Securing them requires moving away from post-deployment containment and toward deterministic, machine-readable pre-deployment certification (Security Stamps).

The Silent Vulnerability in Your AI Pipeline

A pull request lands on Tuesday. It consists of just six lines of code.

It adds a simple tool to an enterprise agent that handles order inquiries – a small helper that looks up a shipment by running a command against an internal CLI. The reviewer reads the diff, sees a sensible, time-saving feature and approves it. The CI/CD pipeline passes, and the code deploys to production that afternoon.

Nothing about that day was negligent. The reviewer verified that the feature worked. The CI pipeline ran unit tests and lint.

Yet a massive security gap was just introduced.

Neither the developer, the reviewer, nor the CI pipeline checked whether the agent's effective reach had changed. Why? Because nothing in the deployment pipeline knew how to represent the agent’s overall assembly as a versioned, enforceable artifact.

Now ask what you would ask of any other production artifact:

• What security posture did we certify?
• When did we certify it?
• Against which version of our compliance rules?
• Which deployment gate should have failed?

There were no answers, because there was no gate.

What is an "Agent Assembly"?

The root of the problem lies in a common conceptual error: we treat an AI agent as a service, a file, or a model with some glue around it. It is none of those.

An agent is an assembly of moving parts: application code, prompt templates, tool grants, MCP configuration, and model binding, combined into one operational unit.

The production components come from different repositories, are versioned separately, and become risky mainly in combination.

The true production artifact is not the agent’s code. It is the complete agent assembly — the collection of components that determines what the agent can actually do. The rest of the article treats the agent assembly as the production artifact – just as it should be.

Applying Proven Software Supply Chain Security to AI

In traditional enterprise software, we already know how to solve this problem.

Think about a container image between build and production.

1. It gets scanned, the findings are tied to a specific cryptographic digest.
2. It is digitally signed and the signature is attached to that digest. A Software Bill of Materials (SBOM) travels with it.
3. At the cluster boundary, an admission controller blocks the run if the signature is missing or if policy is violated.

The same pattern must be applied to AI agents. It requires:

A machine-readable verdict, bound to a specific artifact version, checked at a gate that can block it.

Read that sentence again:

• Machine-readable, so it’s enforceable by CI gates, CD gates, or the cluster boundary
• Verdict bound to a specific artifact version, so it changes with versions, and more importantly, there is something concrete to check
• A gate that enforces the verdict, because a security decision that nobody enforces is documentation.

The agent assembly is not usually a single build output. There is no standard canonical digest for the complete assembly. Some of the assembly lives in the repository, some in configuration and some are resolved at launch. There is no single object to hash and sign by default, so there is nothing obvious to bind a verdict to.

Why Have AI Agents Fallen Out of This Pattern?

Not because anyone decided they should. The assembly breaks the assumptions the pattern rests on.

1. The risk is in the composition, not individual components. You can review all five parts and find nothing wrong with any of them individually. The tool is fine. The prompt is fine. The permissions are defensible in isolation.
2. The real danger is in the combination: This agent, holding this grant, reading content from that source. File-level review does not surface a risk that is not contained in just one file.
3. In many agent stacks, no single system sees the whole artifact. CI sees a repository. The platform registry sees registration and deployment. CI does not know which grants were bound at deploy time. The registry does not know what the code does with them. Neither has enough context to certify the assembly.
4. The assembly can change without a conventional build. Swap the model binding. Edit a prompt template. Add an MCP server to a configuration file. Each can change behavior, sometimes dramatically, without producing a new build artifact. The pipeline is waiting for an event that never fires.

That last point matters the most. The problem is not only that we lack a gate. We also lack the trigger that would tell the gate to run.

The Containment Fallacy: Why Runtime Guardrails Aren't Enough

The tools we bought solve a different problem.

Most organizations taking agent security seriously have some combination of agent identity, sandboxing, Data Security Posture Management (DSPM), runtime guardrails, and posture management that maps deployed agents and flags toxic permission combinations.

Those controls are useful. If you do not have agent identity, start there. But notice what they share: they are containment controls. They constrain what an agent can do once it exists and is running.

They answer, 'How bad can this get?' rather than 'Should this have shipped?'

Most also operate after deployment. Posture management discovers the agent after it reaches the cloud account. Runtime guardrails engage when a request is already in flight.

We have built substantial infrastructure for containing bad agent behavior and far less for certifying the complete assembly before it ships.

The Missing Primitive: The AI "Security Stamp"

To bridge this gap, enterprises must introduce a Security Stamp, a digital verdict bound to the complete agent assembly. To be effective, this Security Stamp must possess five properties:

1. Machine-readable: A gate is code. It needs structured data, not a Jira ticket saying that security reviewed the release.
2. Bound to the whole assembly: Derive a canonical assembly hash from the components. If even one component changes, the stamp no longer applies. That creates the trigger the current pipeline lacks.
3. Reproducible: The same inputs should produce the same result. The security analysis should not depend on where the scan happens to run.
4. Evidence-linked: The stamp should reference the findings and rule versions that produced the verdict.
5. Expiring: A certification issued against March rules cannot account for an attack class discovered in June. A stamp without an expiry turns a snapshot into a permanent claim.

From Assembly to Runtime

If the stamp is missing, expired, or bound to a different assembly hash, deployment is blocked. The flow is straightforward:

The important part is that the five components become one certifiable production artifact before deployment.

What an Agent Security Stamp Looks Like

The details will vary by platform, but the structure should remain recognizable:

{
  "agent": { "id": "order-enquiry-agent", "registry": "bedrock-agentcore" },
  "assembly_hash": "sha256:4c1f...",
  "components": {
    "code": "sha256:9ab3...",
    "prompts": "sha256:71de...",
    "tool_grants": "sha256:00c5...",
    "mcp_config": "sha256:e42f...",
    "model_binding": "sha256:b108..."
  },
  "tier": "T2",
  "verdict": "allowed",
  "evidence": {
    "scan_id": "scn-20260318-0442",
    "rule_packs": ["air-core/2026.03", "nvidia-skillspector/2.0.0"],
    "findings_uri": "https://example/scans/scn-20260318-0442"
  },
  "issued_at": "2026-03-18T09:14:22Z",
  "expires_at": "2026-04-17T09:14:22Z"
}

The tier here is illustrative; how tiers are defined is the subject of the next part.

If you already sign image attestations, do not invent a new envelope. This can be expressed as an in-toto predicate: the same machinery, answering a new question.

Provenance tells you how something was built. The stamp tells you what it is permitted to do.

An assembly can have flawless provenance and still combine shell access with untrusted input. Two design choices matter more than the field names.

1. Write the stamp back to the registry that already owns the agent. The platform already knows the agent exists and controls its deployment path.
2. Keep the gate simple. It should ask only whether a stamp exists for this assembly hash, whether it has expired, and whether its verdict permits the target environment. The analysis happens earlier.

Why the Verdict Cannot Be ‘Yes’ or ‘No’

Consider one finding: a tool returns output that flows back into the model's context without validation.

For an agent that reads a public FAQ, that may be close to noise. For an agent with write access to order management, it creates a credible attack path. Anyone who can influence the tool output may influence what the model does next, and what it does next includes writes.

The findings and rules are identical. The decision about shipping is not. A finding describes a condition. A verdict describes whether that condition is acceptable for this agent, its capabilities and its environment.

A Boolean stamp forces one threshold across both agents. Set it too strictly and teams will route around a gate that blocks low-risk systems. Set it too loosely and the order agent passes. Neither approach survives contact with a real platform team.

The verdict therefore must be contextual. It needs a definition of what this agent is permitted to be. That is the role of a risk tier, and it is the subject of the next part.

Three Prerequisites for Implementing Pre-Deployment Agent Security

The design is simple on paper, but three prerequisites determine whether the stamp means anything:

1. The scan must be deterministic. The same inputs should produce the same findings on a developer laptop and a CI runner. Absolute paths, line numbers, unsorted directory traversal, or a model in the verdict path can all break reproducibility. Detection should remain rule-based, not inferred.
2. Identity must survive the build-to-runtime boundary. The agent in the repository and the agent registered on the platform must resolve to the same identity. Declared names, such as a tool wire name or registered agent name, are usually more reliable than values derived from file paths because both sides can observe them.
3. The deployment path must enforce the result. If no deployment path reads the stamp, the system is only producing security notes.

Back to Tuesday: The Safe Way to Ship

With a stamp in place, the six-line pull request is blocked, but not because a reviewer became more perceptive.

The six-line change altered the tool-grant set. That changed the assembly hash, invalidated the existing certification, and caused the deployment gate to fail.

The judgment happened earlier. At deployment, the gate only checks whether it still applies.

This is not a new security idea. It is the discipline we already apply to container images, extended to the artifact we are now shipping fastest.

The thesis for this series is that agent assemblies need four connected controls:

A certification that nothing enforces is documentation. A gate without tiering blocks everything or nothing. Certification without revocation assumes that today's rules will never change.

The next part will cover risk tiering: how autonomy, blast radius, reversibility, and data sensitivity shape what an agent should be permitted to do.

Tredence’s Strategic Approach to Agentic Lifecycle Security

At Tredence, security is engineered into every stage of the agent lifecycle, from design to decommissioning. This is Agentic Lifecycle Security in action. By building deterministic scanning, an AI risk registry and evidence-linked certification into reusable accelerators, we help teams ship agents at speed without trading away security or trust.