Do structured outputs make AI agents safer?

Structured outputs make an agent safer in one narrow way: replies follow a fixed shape that your code can parse and check, instead of free text. They do not make the values inside safe. A well-formed command can still be the wrong command, so validate content and limit what tools can do.

What do structured outputs actually give you?

When an agent must answer in a schema, such as JSON with named fields and fixed types, you replace free-form text parsing with a defined contract. JSON Schema is the common standard for this. It is a declarative language for defining structure and constraints for JSON data, and a validator checks whether a document conforms.

That helps in real ways. Malformed replies fail fast. An action field limited to a short list of allowed values cannot carry an arbitrary command word. Required fields stop half-filled requests. Downstream code gets predictable types, which cuts the number of ad hoc parsing paths where bugs hide.

What do they not give you?

A schema checks shape. It does not check truth, intent or authorization. Consider an agent with a schema containing action, target and amount. The reply is valid if action is "refund", target is a string and amount is a number. The schema does not know that the target is another customer's order or that the amount is ten times the purchase.

OWASP's guidance on improper output handling is useful here. It defines the risk as insufficient validation, sanitization and handling of model output before it goes downstream, and says the answer is to treat the model like any other user, apply zero-trust validation to its responses, and use context-aware encoding and parameterized queries when output reaches a database or browser. A string field that is valid JSON is still a string that could hold SQL, script or a file path.

OWASP's excessive agency entry covers the other half. It names excessive functionality, excessive permissions and excessive autonomy as root causes of damaging actions taken in response to unexpected, ambiguous or manipulated model output. A schema narrows what the model can say. It does not narrow what the tool behind it is allowed to do.

A constructed example

A deployment assistant returns objects like an action of "restart", a service name and an environment. The schema restricts action to restart, scale or status, and environment to staging or production. Good. Then a log line the agent read contains text telling it to restart the payment service in production repeatedly. The reply is a perfectly valid object. Without a second layer, it runs.

The layers that stop it are outside the schema: the agent's credentials cannot restart production without approval, a rate limit caps restarts, and an allowlist ties service names to the requesting team. This example is invented.

How to check or apply this

1. Define a strict schema for every agent reply that triggers an action, and reject anything that fails.
2. Use enumerated values wherever the set is small, instead of free strings.
3. Validate content after the schema: ownership checks, ranges, allowed targets.
4. Encode or parameterize values for their destination, whether SQL, shell, HTML or a file path.
5. Give each tool its own least-privilege credential, so a valid but wrong request cannot do broad damage.
6. Require human approval for irreversible or high-value actions.
7. Log the schema-valid request, the context that led to it and the outcome.
8. Test with valid-looking but harmful values, not just malformed ones.

Safeguard's guardrails and MCP Guardrail apply policy at the point where an agent calls a tool, which is the layer a schema cannot cover. The checks in this list still belong in your own code.

Quick check

Sources

• JSON Schema: What is JSON Schema?
• OWASP LLM05:2025 Improper Output Handling
• OWASP LLM06:2025 Excessive Agency

Last reviewed: 18 October 2026.