Use pre-built policy tiers

Agent Guard publishes four pre-built policy tiers on the public Jozu Hub. Each tier is an OCI artifact containing a bundle of ArtifactPolicies and ToolPolicies tuned for a different risk tolerance. Pick the one that matches your situation, or compose two tiers to combine their effects.

The four tiers

Tier	Ref	What it does
Strict	jozu.ml/jozu/agentguard-policies:vm-strict	Localhost-only network. All git push blocked. Credential access blocked. apt-get install requires confirmation.
Standard	jozu.ml/jozu/agentguard-policies:vm-standard	Domain-allowlisted network. Force push blocked. Destructive commands (rm -rf, DROP TABLE) require confirmation.
Permissive	jozu.ml/jozu/agentguard-policies:vm-permissive	Open network with known exfiltration patterns blocked. Only force push to main is blocked.
Supply Chain	jozu.ml/jozu/agentguard-policies:vm-supply-chain	ArtifactPolicy that blocks pulls from untrusted package registries and ArtifactPolicies that block curl with embedded tokens. Designed to layer on top of any tier.

How to install a tier

agentguard policy add jozu.ml/jozu/agentguard-policies:vm-standard

Confirm it loaded:

agentguard policy list

The policy is now active for every agentguard run until you remove it.

Always include the registry hostname in the ref. The public Hub uses jozu.ml/. If you run a private Hub, use your Hub's domain:

agentguard policy add hub.acme.com/jozu/agentguard-policies:vm-standard

If you leave the hostname off (a bare jozu/agentguard-policies:vm-standard), Agent Guard resolves it against the local registry, which is only what you want when testing locally.

The registry host is recorded in ~/.agentguard/config.json and reused for every subsequent sync.

Picking a tier

Use this decision table.

• You are evaluating Agent Guard for the first time and want to see policy in action: Standard. It blocks the things most teams care about (force push, destructive operations) without locking the agent down so hard that you cannot get useful work done.
• You are running an agent in a sensitive context (production data, regulated workload, untrusted code review): Strict. The localhost-only network is the strongest control and forces every external call through the audit log if you want to allow it.
• You are running an agent against your own personal projects and want minimal friction: Permissive. Only the things that are almost always wrong (force push to main, plaintext credential exfiltration) are blocked.
• You want supply chain protection regardless of which other tier you use: Supply Chain. Layer it on any tier.

Composing tiers

The Supply Chain tier is designed to overlay another tier. Add both:

agentguard policy add jozu.ml/jozu/agentguard-policies:vm-standard
agentguard policy add jozu.ml/jozu/agentguard-policies:vm-supply-chain

Both bundles load and both are evaluated on every tool call. ArtifactPolicies in either bundle are evaluated on every artifact pull. If any rule in any bundle blocks an operation, the operation is blocked.

You can also mix in your own policies. Local files in ~/.agentguard/policies/global/ are evaluated alongside any tier you have added.

Why the Supply Chain tier is an ArtifactPolicy

It blocks the registry rather than the install command, so it stays effective regardless of which install tool the agent reaches for. See Picking the right kind for the reasoning.

Pinning to a specific version

Tier refs include a tag (:vm-standard, :vm-strict). The same tag can be updated by Jozu when new rules are added. To pin to a specific snapshot, use the digest form:

agentguard policy add jozu.ml/jozu/agentguard-policies@sha256:abc123...

Pinning is most useful in CI or shared deployments where you want every run to see exactly the same policy.

Removing a tier

agentguard policy remove jozu.ml/jozu/agentguard-policies:vm-standard

See Manage policies for the full management flow.