Skip to main content
Roll out Forge in stages so each new control is backed by current inventory, resolved identities, and evidence your team can verify.

​
1. Establish identity and ownership

Connect your directory first. Confirm that users and groups appear in Forge, then assign owners for policies, AI systems, and business groups. Add service accounts and Agent identities for non-interactive workloads that will use Forge gateways or provider access. Use Identity types to choose the correct identity for each workload. Review Ownership before enabling approval policies so requests reach the right reviewers.

​
2. Connect discovery sources

Start with the systems that describe the broadest part of your estate:
  • Cloud and SaaS platforms for managed AI services, workloads, and accounts.
  • GitHub and other repositories for AI applications, MCP servers, skills, and configuration.
  • Network integrations and Forge for devices for observed use and local tools.
  • Enterprise AI providers for platform-native activity and history.
Use Test before saving a connection, then run Sync. A successful test proves the supplied connection can authenticate; the sync result shows which evidence families Forge actually collected.

​
3. Review inventory and activity

Open Inventory to confirm that expected products, agents, MCP servers, skills, identities, and workloads are present. Investigate unmanaged or unexpected assets before treating the initial inventory as an approved list. Open Sessions to verify that fresh activity is attributed to the expected user, product, source, and organization. Review source coverage when content or identity fields are absent rather than assuming Forge inferred them.

​
4. Introduce governed access

Add MCP servers and skills to the Registry, review their risk information, and publish them to a small audience. Configure LLM Gateway routes, provider credentials, models, and budgets for a pilot workload. Keep discovery, publication, and runtime authorization separate: an asset can be visible in Inventory without being approved in the Registry, and Registry approval does not override gateway policy.

​
5. Add policies

Start with a narrow pilot group and an outcome that is easy to observe. Then expand from review or guidance to transformations, approvals, and blocking as your evidence and ownership routes are proven. Use Author policies for the Console workflow. Verify each policy in Sessions and Violations, and verify approvals and grants in Responses.

​
6. Configure response and delivery

Confirm ownership routing, reviewer permissions, approval scope, and grant expiration. Connect Slack, the organization webhook, and an audit-log export destination where required. Send a test notification or export before relying on the integration for an incident.

​
Acceptance checklist

Before expanding beyond the pilot, verify that:
  • Directory users, groups, service accounts, and Agent identities resolve as expected.
  • Each integration reports a current successful Test and Sync result, with any partial evidence clearly understood.
  • Inventory and Sessions contain fresh records from the intended sources.
  • A real LLM request and MCP tool call succeed through the configured gateways.
  • A policy allow, visible review outcome, and blocking outcome behave as intended for the pilot identity.
  • The policy occurrence links to its Session and appears in Violations when configured to create one.
  • An approval reaches the expected owner and the resulting grant is visible in Responses.
  • Slack, webhook, and audit export tests reach their configured destinations.
Expand one audience or source at a time, then repeat the relevant checks. This makes attribution, missing permissions, and policy scope errors easier to isolate.