The first generation of agent security asked whether the model was safe. The current generation has to ask a harder question: whether the things the agent reaches for are safe, and whether the agent can be trusted to reach for them. An autonomous agent is a program that takes instructions from wherever it reads, including the tools it uses. That property is what makes it useful. It is also what makes it an attack surface with a shape most security tooling was not built to see.

This is a teardown of that problem as it stands in 2026, and of the approach Helocast takes to it. It is a capability piece, not a product pitch. The point is to be precise about the threat and honest about what actually contains it.

The agent supply chain is the attack surface

An agent's power comes from its tools and skills. A skill is code plus metadata that tells the agent what the tool does and when to use it. That metadata is instructions the agent reads at decision time, from a source that is often not the operator. Three failure modes follow directly.

  • Malicious skills. A skill installed from an untrusted source can carry logic that acts against the operator: exfiltrating data it touches, calling other tools in a chain the operator never intended, or quietly changing what a benign-looking action does.
  • Tool poisoning through metadata. The description of a tool is prompt content. An attacker who controls a tool's metadata, or a tool result the agent reads, can inject instructions that steer the agent. The classic form is a tool whose description says one thing to a human reviewer and another thing to the model. This is prompt injection delivered through the supply chain rather than through the user's message.
  • Confused-deputy tool chains. An agent holds credentials and reach that the untrusted input does not. Injected instructions do not need to break the agent. They only need to convince it to use its legitimate access on the attacker's behalf.

The common thread is that the agent is doing exactly what it was told, by an input that had no business telling it. The vulnerability is not a bug in the runtime. It is the runtime working as designed on hostile instructions.

Why static defenses are not enough

The instinct is to scan. Maintain a blocklist of bad skills, run signature detection over skill code, and reject known-bad patterns before install. This is necessary and it is not sufficient, for reasons that are structural rather than a matter of better rules.

  • The payload is natural language. A poisoning instruction hidden in tool metadata is not a code signature. It is a sentence. Signature scanners built for malware do not catch a well-phrased instruction, and the space of phrasings is unbounded.
  • Behavior is contextual. The same tool call can be benign or hostile depending on what preceded it and which task is running. A static scan of a skill in isolation cannot see the chain it will participate in.
  • Blocklists are always behind. A list of known-bad skills is a list of yesterday's attacks. The agent supply chain produces novel skills continuously, and a defense that only recognizes what it has seen before concedes the first move to the attacker.

Static analysis at install time is a real layer. It filters the obvious. But an agent's risk is decided at runtime, in the chain of actions it actually takes, and that is where the enforcement has to be.

The approach: govern at the point of action

Helocast treats the agent runtime the way you would treat any untrusted principal that holds real access. You do not try to prove it is safe. You bound what it can do, watch what it does, and contain it when its behavior drifts. Four elements carry that.

Semantic pre-load skill analysis

Before a skill is admitted, analyze it for what it actually asks the agent to do, not just for known-bad signatures. The unit of analysis is the skill's declared behavior and its metadata read as instructions: what tools it composes, what data it touches, and whether its human-readable description matches its machine-readable effect. A skill whose description and behavior disagree is a poisoning candidate and is held for review. This is semantic because it reasons about meaning and intent, which is the layer the attack lives on.

Learned, behavioral capability scoping

Each class of task has a shape: the tools it legitimately uses, the order it uses them in, the data boundaries it stays within. Establish that shape, then scope the agent's capabilities to it at runtime. When a running task reaches for a tool outside its established behavior, that is the signal. The scoping is learned rather than hand-listed because the space of legitimate behavior is too large to enumerate by hand and drifts as tasks evolve. The enforcement is behavioral because the decision depends on the sequence, not on any single call in isolation.

Containment over hard-kill

When a task crosses a line, the default response is to contain, not to terminate. Narrow the task's capabilities, pause it for review, or drop it into a reduced-privilege mode where it can still be inspected. Hard-kill throws away the evidence and turns a security event into an availability event. Containment keeps the task observable, lets an operator see what the agent was steered toward, and degrades the system gracefully. Hard-kill remains available for the cases that warrant it. It is not the reflex.

Skill provenance and attestation

Every admitted skill carries a provenance record and an attestation from an approved source, so the question "where did this capability come from" always has an answer. Provenance does not prove a skill is safe. It makes the supply chain accountable, shrinks the set of skills you have to reason about to those from sources you have vetted, and gives an assessor a clean chain of custody.

How it deploys

The governance runs as a policy enforcement point in front of the agent runtime. Every tool call the agent wants to make passes through it before dispatch. The enforcement point consults the learned behavioral policy, checks the call against the task's established shape and the skill's provenance, and returns allow, contain, or deny. Because it sits in the request path rather than beside it, an agent cannot route around it: a tool call that does not pass through the enforcement point does not happen.

flowchart LR
  IN[Untrusted input, tool metadata, tool results] --> AGENT[Agent runtime]
  SKILL[Skill] -.pre-load analysis.-> ADMIT{Admit?}
  ADMIT -->|held for review| REVIEW[Quarantine]
  ADMIT -->|admitted with provenance| AGENT
  AGENT -->|proposed tool call| PEP[Policy enforcement point]
  PEP -->|matches task shape| ALLOW[Allow and log]
  PEP -->|drifts from shape| CONTAIN[Contain and inspect]
  PEP -->|clear violation| DENY[Deny and log]
  ALLOW --> TOOLS[Tools and systems]

Figure 1. Skills are analyzed before admission. Every tool call is judged at runtime against the task's learned behavioral shape, with containment as the middle response between allow and deny.

How it is measured

A defense you cannot measure is a claim, not a control. The honest way to evaluate runtime agent governance is against adversarial benchmark families that model the actual attacks, run as a harness rather than a one-time demo.

  • Tool-poisoning suites. Batteries of tools whose metadata carries injected instructions, scored on whether the governed runtime refuses or contains the steered action while a control run is compromised.
  • Confused-deputy scenarios. Tasks where injected input tries to turn the agent's legitimate access against the operator, scored on containment.
  • Benign-behavior regression. A companion suite of legitimate tasks, to measure how often governance blocks work it should allow. A control that stops the attacks by stopping the agent is not a control.

The measurement approach matters more than any single number. Report the evaluation harness, the benchmark families, the attack and the benign suites, and the containment rate against the false-positive rate. Numbers without that scaffolding are not evidence, and this work is read by people who know the difference. Helocast builds the harness alongside the defense so the two evolve together, and so the customer can re-run the evaluation after we leave.

Where this fits

Runtime governance is the enforcement layer that makes the broader secure agentic AI reference architecture trustworthy. The cluster design bounds where the agent can reach. This layer bounds what the agent decides to do with that reach. Together they let an organization run autonomous agents on real systems without accepting the agent's judgment on faith, and they produce the behavioral evidence an authorizing official needs to sign. Seen from the deployment side, this is the same instinct behind deploying a governed agent workflow: govern at the point of action, keep the operator channel unforgeable, and treat the workload as untrusted. Model-agnostic by design: the governance reasons about skills, tool calls, and behavior, which are the same regardless of which model sits behind the runtime.