Team and enterprise deployment

The same Agent Guard binary that an individual developer runs on their laptop also runs across a fleet of developer machines and CI runners. This page covers the patterns organizations use to scale Agent Guard beyond one developer.

Three roles tend to drive the rollout: a security admin who owns the corporate baseline, team leads who layer team-specific rules on top, and a platform engineer who automates installation and registry access across the fleet. The features Agent Guard exposes are the same in all three cases; the difference is which scope they operate at.

The security admin: publish the baseline

The security admin owns the rules that apply to every developer on every project. Direct push to protected branches, credential file reads, network calls to disallowed hosts, anything that should never happen in any context.

The pattern is one global policy source that every developer machine pulls from.

# Admin: pack and push the baseline to a private Hub
kit pack . -t acme-corp/security-baseline:v3
kit push acme-corp/security-baseline:v3 hub.acme.com/acme-corp/security-baseline:v3

# Admin: sign with cosign for tamper detection
cosign sign hub.acme.com/acme-corp/security-baseline:v3

# Each developer (one-time setup, automated via MDM)
agentguard policy add hub.acme.com/acme-corp/security-baseline:v3 \
  --pub-key /etc/agentguard/cosign.pub

From this point forward, every agentguard run on every developer machine pulls the latest signed version of the baseline. When the admin publishes a new revision of :v3, developers get the update on their next run without any manual intervention.

Two things make this work cleanly.

• Global scope. The admin adds the policy without -w, so it applies to every workspace.
• Signature verification. With --pub-key configured, a policy revision that was not signed by the corporate key is rejected on sync. This catches both accidental misconfiguration and targeted tampering.

See Manage policies for the full add and verify flow.

The team lead: layer team rules on shared repos

A team lead manages developers who work on a shared set of repositories with rules that go beyond the corporate baseline. Maybe the payments team forbids direct database CLI access. Maybe the frontend team blocks force-pushes to all main branches, not just the corporate-protected ones.

The pattern is one workspace-scoped policy source per team repo.

# Team lead: pack and push the team policies
kit pack . -t acme-corp/payments-policies:v1
kit push acme-corp/payments-policies:v1 hub.acme.com/acme-corp/payments-policies:v1

# Each team member (documented in the team wiki or repo README)
agentguard policy add hub.acme.com/acme-corp/payments-policies:v1 -w ~/projects/payments-api
agentguard policy add hub.acme.com/acme-corp/payments-policies:v1 -w ~/projects/payments-frontend
agentguard policy add hub.acme.com/acme-corp/payments-policies:v1 -w ~/projects/payments-worker

When a developer runs agentguard run claude-code --workspace ~/projects/payments-api, the effective policy set is the union of the corporate baseline and the payments policies. When they switch to a non-payments repo, only the baseline applies. This is automatic and requires no thinking on the developer's part.

To update the team policies for everyone at once, push a new revision of :v1. The next run picks it up.

To roll out a breaking change that needs explicit opt-in:

# Publish a new major version
kit push acme-corp/payments-policies:v2 hub.acme.com/acme-corp/payments-policies:v2

# Team members migrate workspace by workspace
agentguard policy remove hub.acme.com/acme-corp/payments-policies:v1 -w ~/projects/payments-api
agentguard policy add hub.acme.com/acme-corp/payments-policies:v2 -w ~/projects/payments-api

The platform engineer: automate everything

The platform engineer owns the rollout across the fleet. Their job is to make sure every developer machine and every CI runner has Agent Guard installed, the baseline policy configured, signature verification enabled, and the audit log going somewhere central.

The pattern is an onboarding script distributed via MDM or run as part of new-machine provisioning.

#!/bin/bash
# onboard-agentguard.sh

set -euo pipefail

# Install Agent Guard
curl -fsSL https://raw.githubusercontent.com/jozu-ai/agentguard/main/scripts/install.sh | bash

# Authenticate to the private Hub
agentguard policy add hub.acme.com/acme-corp/security-baseline:v3 \
  --pub-key /etc/agentguard/cosign.pub \
  -u "$AGENTGUARD_REGISTRY_USER" \
  -p "$AGENTGUARD_REGISTRY_TOKEN"

# Verify
agentguard status
agentguard policy list

A few things to know when automating Agent Guard:

• Override the data directory for shared or non-standard machines. Set AGENTGUARD_HOME=/opt/agentguard (or any path) before running. CI runners and shared development hosts where individual home directories do not make sense.
• Disable auto-sync for offline machines. Set AGENTGUARD_NO_SYNC=1 to skip the per-run sync. The machine uses its cached policies until you explicitly run agentguard sync.
• Point audit logs at your aggregation tool. Configure Splunk, Datadog, or whatever you use to tail ~/Library/Logs/AgentGuard/policy_audit.jsonl. The file is newline-delimited JSON, so most log shippers handle it without configuration.

Repository-level convention

For each repository the team owns, a Makefile target or setup script tied to clone-time can configure the workspace-scoped policies automatically:

# In the repo's Makefile
.PHONY: setup-agentguard
setup-agentguard:
	agentguard policy add hub.acme.com/acme-corp/$(shell basename $(CURDIR))-policies:latest -w $(CURDIR)

A new developer cloning the repo runs make setup-agentguard once. From then on, every Agent Guard run against this workspace gets the team policies.

Staging and production policy tracks

Some organizations want a staging policy that gets validated before promotion to production. The Hub tag is the natural mechanism.

# Staging tag: developers running the staging policy can hit edge cases
agentguard policy add hub.acme.com/acme-corp/security-baseline:staging

# Production tag: stable, vetted policies
agentguard policy add hub.acme.com/acme-corp/security-baseline:v3

When :staging has been running for long enough without issues, the admin promotes it by pushing the same content under :v3 (or :v4 if a major version bump is warranted). Developers tracking :v3 get the new content on next sync.

To roll back, push the prior content under :v3 again. The next run picks up the rollback.

Why this requires a private Hub for any real org

Production team and enterprise rollouts depend on shared org namespaces (so refs like acme-corp/security-baseline exist), customized security scans, custom deployment artifacts (RICs and custom skills), and storage and bandwidth limits that scale. None of these are available on the free public Hub. See Where Agent Guard fits in Jozu for the side-by-side comparison.

The private Hub deploys as a versioned Helm chart on your existing Kubernetes infrastructure. Contact Jozu for access.