> ## Documentation Index > Fetch the complete documentation index at: https://docs.ultra.security/llms.txt > Use this file to discover all available pages before exploring further. # Rollout Guide > How to implement full Ultra coverage across your organization Ultra runs next to your agent or harness. The tools your agents call route through it, so their activity is recorded and can be governed. Rolling Ultra out across an organization takes four steps: set up your organization, install onto devices, tailor your security controls, then monitor traffic. Each step has a page covering the mechanics. This guide is about the order and the decisions in between. ## 1. Set up your organization Create your organization, teams, and workspaces, then add members by invite, directory sync, or beacon. [Onboarding](/hub/onboarding) walks through all of it. [Workspaces](/hub/workspaces) group devices and their traces, and can receive targeted policies. Common workspaces include laptops, CI/CD, cloud agents, staging, and production, and they can just as easily follow teams, such as customer support and security. If organizing your devices that way would be useful, we suggest creating those workspaces up front, so guardrails and connectors can be scoped to a workspace when you reach step 3. If a single policy suits everything you run, one workspace is enough. Your organization starts with every built-in [guardrail](/hub/guardrails) in **Monitor** mode, [anomaly detection](/observability/anomaly-detection) on a 24-hour cadence, and governance posture at `default_allow`. Nothing is blocked or redacted until you change it. ## 2. Install onto devices Devices connect by browser sign-in, [deploy key](/hub/deploy-keys), or MDM. [Onboarding](/hub/onboarding) covers each, and [Install Ultra](/installation/install-ultra) covers the installer itself. Install on one device first and check it there before going wider. Ask your agent *"Call the Ultra Servers tool and show me my connected servers"*, have it use one of those connectors, then confirm the call appears in [Traces](/observability/traces). Then roll out in cohorts: your security team first, then one more team, then wider. Ultra picks up the connectors already configured in each agent on first start, so nobody reconfigures anything by hand. ## 3. Tailor your security controls Your organization is already running every built-in guardrail in Monitor. This step is where you turn that up and decide what agents can reach in the first place. Two controls, and most organizations want both. [Guardrails](/hub/guardrails) decide what an individual action is allowed to do. They inspect the action itself, so they work from the first call. Promote any guardrails as needed from **Monitor** to **Block** or **Redact**. [Governance](/hub/governance) decides which connectors and tools are reachable at all. It works from your inventory, so it covers what Ultra has already seen and widens as your catalog fills in. Posture sets the baseline for actions that no rule matches: `default_allow` permits everything except what you block, `default_deny` permits only what you approve. Set the organization to the most permissive posture you want, then tighten individual workspaces according to desired policy. Because governance depends on inventory, a connector nobody has used yet cannot be blocked by name, and `default_deny` usually lands later than your first guardrail promotions. ## 4. Monitor traffic Your [tool catalog](/hub/tools) fills in with the connectors and tools your agents actually reach for, and [Traces](/observability/traces) shows what they did with them. [Anomaly detection](/observability/anomaly-detection) scans that traffic on a schedule, looking for suspicious patterns and recording each finding with a risk score. It starts on a 24-hour cadence, adjustable down to 15 minutes if you want issues surfaced sooner. A new organization raises no alerts until you switch sources on, so open Configuration in [Alerts](/observability/alerts) and enable the guardrail, governance, and anomaly sources you want. As the catalog settles, come back to step 3: extend governance to cover what has appeared, and move a workspace to `default_deny` once its inventory looks stable. ## What's next Create your organization and bring people and devices onto it Enforcement modes, dry-run testing, and the built-in catalog Posture, allow and deny rules, and drift enforcement The guide to hand to everyone you are onboarding This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.