How is activity schema validation different from setting system prompt instructions that restrict what the agent does?

System prompt instructions operate on text that passes through the model, and researchers have demonstrated that social engineering techniques reliably bypass those restrictions at the model layer. Schema validation operates on structured span data, tool names, argument payloads, and call sequence metadata, before or after the model produces output, so bypassing it requires defeating the instrumentation layer rather than the prompt.

What happens if a legitimate workflow triggers a schema violation because a tool is called in an unexpected order?

That is a signal to refine the schema, not to disable validation. Run in monitor mode first to collect the actual call patterns your approved workflows produce, then use that data to write sequence constraints that reflect real behavior. A violation in monitor mode generates an alert and a record without blocking the call, so you can tune the schema before switching to enforce mode.

How granular does a schema need to be to catch the kind of drift in the trojanized skills campaign?

A simple permitted-tools allowlist, where the schema names every tool the agent is authorized to invoke by identifier, would have flagged the malicious skill on its first call. The trojanized skills introduced new tool names that no legitimate schema would have listed. Full argument-level and sequence constraints add depth but are not required to catch a novel tool invocation.

Does every agent need its own schema, or can a shared schema cover multiple agents?

Each agent should have its own schema if their permitted tool sets or privilege levels differ, which they almost always do in practice. A shared base schema for common read-only tools is reasonable, extended with agent-specific rules for anything that writes, escalates, or handles credentials. Using one schema across agents with different risk profiles means the schema is written to the most permissive agent and provides no boundary for the others.

Detecting agent drift through activity schema validation

What activity schema validation does for you

When an agent starts calling tools it was never meant to call, or escalates permissions in a sequence that no approved workflow requires, the problem rarely announces itself. The agent keeps running, logs keep flowing, and the first signal is often a downstream incident. Activity schema validation changes that by treating each recorded span as something to check against a declared behavioral contract, not just a record to store.

This matters now. Security researchers disclosed privilege escalation paths in Google's Agent Development Kit this week, and a separate campaign delivered 1.7 million combined downloads of trojanized agent skills designed to steal credentials before discovery. Both incidents exploited the gap between what an agent is supposed to do and what it actually does at runtime, a gap that observability alone does not close.

Why observability is not enough

Recording spans tells you what happened. Validating spans against a schema tells you whether what happened was permitted. The distinction is the same as the one between a server access log and a firewall rule: both produce records, but only one blocks unexpected behavior at the boundary.

Watching your agents is not evaluating them, and that gap carries real cost. 1 in 8 enterprise security incidents now involves an agentic system as either the primary target, a contributing vector, or an amplifier, according to combined data from CrowdStrike and Mandiant incident response. A system that only records spans will capture the breach clearly. It will not prevent it.

The trojanized skills campaign illustrates this precisely. Skills installed from a third-party marketplace ran inside agents that had no mechanism to compare actual tool invocations against an expected set. The credential-stealing calls looked like ordinary outbound requests in the span log. Without a schema declaring which tools are permitted, in what order, and with what argument shapes, there is nothing to compare against.

What an activity schema contains

An activity schema is a machine-readable declaration of expected agent behavior for a given workflow. At minimum it describes:

which tools the agent may call, identified by name and version
the permitted argument types and value ranges for each tool
the allowed call sequence or partial ordering, where sequence matters
the maximum privilege level reachable by any single span
any tools or argument patterns that are explicitly prohibited

A customer support agent schema, for example, might permit `lookup_order`, `issue_refund` (amount below a declared threshold), and `send_email`, in that partial order, and explicitly prohibit any call that writes to user credential fields. When the agent calls `update_password` during a session that started as an order lookup, the validator fires before the call completes.

This is distinct from prompt-level guardrails, which operate on text and can be bypassed through social engineering tactics that security researchers now find reliably defeat AI model safety guardrails. A schema validator operates on structured span data, tool names, argument payloads, and sequence metadata, none of which passes through the model's text output at all.

Where drift enters production

Agent drift, behavioral divergence from the declared schema, enters through several routes:

Dependency updates. A tool library ships a new version that exposes additional methods. The agent framework resolves the update automatically. Spans begin including calls that the original schema never anticipated.

Prompt injection. An external data source, a customer message, a retrieved document, passes instructions that redirect tool selection. The model complies. The schema catches it because the resulting call pattern does not match the declared sequence.

Composed workflows. Multi-agent orchestrators delegate subtasks to sub-agents whose schemas may differ from the parent's. Without per-agent schema validation, a sub-agent can reach permissions the orchestrator was never meant to exercise. This is the class of vulnerability found in the Agent Development Kit research.

Skill marketplace installs. The 1.7 million download campaign reached that scale partly because agent frameworks make third-party skill installation low-friction. A schema that names permitted tools by identifier catches an unlisted skill on its first invocation.

Ghost actions, where agents take steps no one requested, are a documented production failure mode across all of these entry points. Schema validation converts a ghost action from a silent event into a flagged violation.

How span-level validation works in practice

Validation runs against each span as the agent emits it, or as a post-processing step over a span batch, depending on your latency tolerance. The validator receives the span, extracts the tool name, arguments, and position in the call sequence, then checks each field against the schema definition.

A violation does one of three things depending on configuration: it raises an alert and lets the span proceed (monitor mode), it blocks the call and returns an error to the agent (enforce mode), or it quarantines the session and routes it to a human review queue. The right choice depends on the agent's role and the cost of a false positive.

Validating agent behavior against expected outcomes at the span level means you can score quality and risk on the same data. Prefactor records spans via SDK instrumentation, scores each one against a declared schema, and keeps the violation record in an audit trail that timestamps exactly which call diverged and by how much. That record matters for compliance and audit requirements in regulated industries, where "the agent did something unexpected" is not an acceptable incident report.

88% of organizations running AI agents reported a confirmed or suspected security incident in the past year. The common thread across those incidents is not model failure. It is the absence of a declared behavioral boundary that automated tooling can check at runtime.

Writing schemas for your agent types

Schema specificity should match the risk profile of the agent. A RAG retrieval agent that reads documents and returns summaries carries lower risk than an autonomous background agent that writes to external systems on a schedule. For the retrieval agent, a schema that permits only read-class calls with no credential fields in scope is adequate. For the background agent, you need sequence constraints, argument range limits, and explicit prohibition lists.

Access control best practices for AI agents and schema validation are complementary, not substitutes. Access control limits what an agent can reach. Schema validation limits what it actually does within that reach, and catches the cases where access control was misconfigured or bypassed.

Start by writing schemas for the three to five agents that touch external systems or handle user credentials. Those are the agents where a single behavioral deviation causes real harm. Expand schema coverage as you add agents to production.

Where to start

Pull your current span data and identify which tool calls each agent is actually making, then compare that list against what your original design intended. The delta is your first schema draft. From there, add sequence constraints and prohibition lists for any tool that touches credentials or external write operations.

Start evaluating your agents to instrument spans and run schema validation against your live agent traffic, and see the docs for schema definition syntax and enforcement configuration.