AgentGuardBoundaries before capability.
Make agent tool calls subject to explicit policies, limits and inspectable audit records.
Boundaries before
capability.
AgentGuard decides whether a specific tool call is permitted, under which limits, and records the reasoning so the decision can be questioned later.
Policy evaluation
Each tool call is evaluated against a declared policy: role, tool, resource scope and rate limit. A call that matches no rule is denied rather than permitted by default.
Rate-limiting boundaries
Limits are enforced per caller and per tool. Exceeding a boundary produces a refusal with the limit that was hit, not a timeout or an empty result.
Hash-linked audit
Decisions are appended to an audit chain where each entry includes the hash of the previous one. A modified or removed entry breaks verification of everything after it.
Human review
Approval requirements are part of the policy, not a separate workflow. A rule can require an explicit human decision for a specific class of call.
One request.
An explicit boundary.
Explore three fixed policy examples. These examples run only in this page; they do not contact AgentGuard or execute any tool.
Check the service
yourself.
These buttons call a public reference deployment. If the service is unavailable, the panel says so — no result is simulated or substituted.
Live reference checks
Read-only requests to the original AgentGuard demonstration service, separate from the Next implementation. Requests go to a public Cloudflare Workers endpoint.
Not checked. No connection is made until you choose a check.
This checks the service response, not production security or integration with your agents.
What this does
not claim.
Boundaries matter more than endorsements when you are deciding whether to run a system against your own tools.
Rate limits and audit scope
Rate limits and audit scope depend on the implementation and deployment. A demonstration endpoint does not establish production security.
Source and publication
Source availability and publication records do not certify the current Next revision. Review release notes, tests and deployment assumptions for your environment.
Where to go
next.
Four routes: the current development branch, the running documentation, the published original and its permanent record.
The DOI identifies a published record. Consult that record for its exact version and files; it does not automatically identify the latest Next commit.
Start with your
constraints.
Bring your requirements, acceptance criteria and deployment constraints. The fastest way to know if this fits is to describe what you are trying to protect.