Shield360 › Resources › Changelog
What changed.
Each release that changed what Shield360 does, newest first: what it does now, where it stops, and where to read the detail. Nothing here is a roadmap.
Last updated 23 October 2026
23 October 2026
Shield Protect: authorization before execution.
Until now the MCP gateway checked an agent's grant and recorded the call. It now puts one boundary in front of every tool call and refuses what fails it. In the reference deployment, with an environment in enforced mode, no tool call runs without a recorded Shield360 decision. That is a claim about configured policy being enforced, not about detecting every harmful intent.
One boundary, every call
Validate the arguments against the tool's own schema, authorize, reserve, record, then execute. A call that fails any step does not reach the service behind it. A schema the gateway cannot check, or arguments it cannot scan in full, are refused rather than let through.
Security › Agent authorization › ProtectThree modes, observe first
Observe records what enforced mode would have refused; warn tells the agent too; enforced refuses. Every existing environment starts in observe, so nothing changes until an administrator turns enforcement on. Grants, the kill switch, approval rules and the block modes of prompt-injection and sequence policies keep refusing in every mode.
Per environmentAction policies on the arguments
Allow, deny or require approval by what the call actually says: a recipient on an approved list, an amount under a cap, a daily total reserved before the call runs so two calls at once cannot both fit. Conditions are data with a fixed set of operators; there is no expression language and nothing in a policy can run code.
Action policiesApprovals that bind
An approval is tied to the agent, the tool, the exact arguments, the person who asked and the agent's permissions at the time. Used once; changed arguments are another call; a permission change makes it stale. The requester, the agent's creator and the person it acts for cannot approve.
ApprovalsAn action ledger, written first
Every decided call is recorded before it runs: refused, awaiting approval, running, succeeded, failed, or unknown when the service did not answer in time. Names, codes and keyed digests only, never arguments or results. Unknown outcomes are settled by a person; a recording failure never re-runs anything.
Protect › Action ledgerHonest about the rest
The Protect tab names what each surface covers. In-process SDK guards and coding-agent hooks are shown as monitored or partially protected, because code or people on their side can bypass them. Telemetry arriving is never shown as protection. Both SDKs gained an enforcement mode that the environment can raise but never lower, and a fail-closed hook policy can no longer be weakened from the machine.
Protect › What is enforced whereWhere it stops
What Shield Protect does not claim.
- The guarantee holds for tool calls that go through the Shield360 gateway in a deployment where the agent has no other credential and no other network path. The reference deployment ships with the product and includes the script that checks this; a deployment that gives the agent a key or a route is labeled partially protected.
- In-process SDK guards stop supported provider calls before they leave, and fail closed in enforced mode, but code that can disable the SDK can bypass it.
- Coding-agent hooks refuse what the vendor lets them see before it runs; events a vendor reports only after the fact are recorded, not refused.
- Shield360 does not promise a service acted exactly once. It sends the action id as an idempotency key; a service that honors one will not act twice on a retried action.