Skip to main content
Launching Barndoor in production usually means coordinating several workstreams at once: MCP server setup, agent registration, policy design, identity integration, user connectivity, network controls, and client rollout. This checklist pulls the key milestones from the trial and setup guides into one place so your team can track readiness before launch day.
Recommended Use: Work through this checklist with your platform owner, security lead, and application owner together.

​
Source Guides

This checklist consolidates the most important steps from:

​
Go-Live Phases

Before configuring production integrations, confirm that your rollout owners, environment, and success criteria are defined.
  • Confirm who owns the Barndoor production rollout internally.
  • Confirm admin access to the Barndoor production organization.
  • Decide which MCP servers, agents, and user groups are in scope for the first release.
  • Define the launch success criteria.
  • Identify a pilot agent, pilot server, and pilot user cohort for final validation.
  • Document the production Barndoor base URLs your team will use.
Start with a narrow first release. One MCP server, one agent, one policy set, and one client is enough for a safe first go-live.
Use this phase to ensure Barndoor can reliably reach and authenticate to every production MCP server you plan to expose.
  • Register each production MCP server in Barndoor.
  • Confirm whether each server is Barndoor Hosted, Barndoor Curated, or Custom.
  • Set clear names, slugs, and descriptions for each production server.
  • Enter the correct OAuth client credentials or upstream auth configuration.
  • For custom servers, validate the server URL, protocol, issuer, auth endpoint, token endpoint, scopes, and metadata.
  • Complete the OAuth connection flow for each server that requires admin-level setup.
  • Verify the server appears connected and available in Barndoor.
  • Test at least one representative tool call path per production server.
Reference: Registering MCP Servers
Agents should be registered and mapped to the right callback behavior before you let them reach production tools.
  • Register every production agent or application in Barndoor.
  • Confirm the correct application type for each agent.
  • Review callback URLs and allowed logout URLs.
  • Store generated credentials securely.
  • Confirm each agent is associated with the correct internal owner.
  • Verify that the agents included in first release are the only ones intended to receive production access.
Reference: Adding Your Agents
If your rollout depends on enterprise identity or role-aware policy enforcement, complete the IdP integration before launch.
  • Configure your IdP connection in Barndoor.
  • Test SSO login with a standard user.
  • Configure admin role mapping from IdP groups if needed.
  • Verify that admin users receive admin access automatically.
  • Verify that non-admin users remain standard users.
  • Confirm your offboarding path works by removing a user from the mapped group and retesting login.
  • Confirm the user and group attributes needed for production policies are available at runtime.
Reference: Connect your IdP
Production tool access often depends on end-user delegated credentials, so account connection needs to be tested as part of launch.
  • Confirm which MCP servers require user-connected accounts.
  • Connect at least one representative production user account for each required service.
  • Verify OAuth consent and redirect flows work cleanly.
  • Confirm connected accounts appear correctly in Barndoor.
  • Test token refresh behavior or reconnect behavior for long-lived use cases.
  • Confirm users know how to connect and disconnect their accounts.
  • Validate that revoking access at the provider behaves as expected.
Reference: Connecting Accounts to Barndoor
This is the most important pre-launch review. Your production policy model should be explicit, validated, and exercised before real traffic reaches production tools.Policy creation
  • Validate every new policy with the v2 validation endpoint before activation.
  • Create production policies in DRAFT first.
  • Confirm every policy has a clear name and description so admins understand what it governs.
  • Confirm every policy has the correct mcp_server_id.
  • Confirm application_ids are scoped narrowly to the intended agents.
  • Confirm the correct agents are selected for each policy, especially when multiple AI clients are in scope.
  • Review the MCP server metadata and full tool list before deciding what AI should be allowed to access.
  • Toggle off any tool calls that should never be reachable by AI in production.
  • Review rule sets for allow, deny, and conditional behavior.
  • Confirm any condition expressions match your real runtime attributes.
Policy testing
  • Test each policy with representative users, roles, groups, and tool calls before activation.
  • Verify expected allow outcomes for approved actions.
  • Verify expected deny outcomes for prohibited actions.
  • Confirm denied requests are easy to trace back to the exact blocking policy.
Policy lifecycle
  • Promote only reviewed policies to ACTIVE.
  • Confirm your team knows when to use DRAFT, ACTIVE, INACTIVE, and ARCHIVED.
  • Verify inactive and archived policies are removed from the active operational view without losing history.
  • Confirm the team knows when to clone a policy instead of editing a stable production policy directly.
Policy summary view
  • Use policy summary and list endpoints to verify the final production state.
  • Confirm admins can review policy name, status, server scope, agent scope, and last-updated metadata in one place.
  • Verify filters such as agent, MCP server, and status return the expected policy set.
Governance and enforcement visibility
  • Confirm enforcement logs show who made the call, which agent was used, which MCP server and tool were involved, and whether the action was allowed or denied.
  • Confirm denied actions are traceable back to the exact policy or restriction that blocked them.
  • Review policy revision history after changes to confirm auditability.
  • Confirm you know which legacy toggles still exist and when not to use them.
If you are migrating from older policy APIs, make sure your team is using the v2 schema. The current model uses application_ids, authorized, roles_groups, and lifecycle status values like DRAFT and ACTIVE.
Reference: Managing Policies
Once servers, agents, and policies are ready, confirm your target AI clients can connect and behave correctly end to end.
  • Decide which AI clients are in scope for the first production release.
  • Configure each client with the correct Barndoor MCP endpoint.
  • Test authentication from each target client.
  • Confirm only the intended MCP tools appear to the client.
  • Run a representative user workflow in each client.
  • Verify policy enforcement behavior during real tool calls.
  • Capture any client-specific rollout notes for support teams and end users.
Reference: Connect AI clients to Barndoor
If Barndoor needs to reach internal infrastructure, complete network approvals before production traffic starts.
  • Add Barndoor’s static outbound IPs to your firewall allowlist where required.
  • Confirm the required inbound ports are open.
  • Validate that only expected Barndoor traffic can reach your custom MCP servers.
  • Confirm TLS and upstream auth requirements are enforced on custom servers.
  • Review internal logging and alerting for Barndoor-originated requests.
  • Confirm your security team has signed off on the connectivity model.
Reference: IP Whitelisting
Treat this as the final dress rehearsal using the exact production path your users will rely on.
  • Execute one complete end-to-end workflow from AI client to MCP server to downstream system.
  • Verify the expected allow and deny policy outcomes.
  • Validate observability and audit visibility for the workflow.
  • Confirm support contacts are listed on active policies where needed.
  • Confirm revision history is being recorded for the latest policy changes.
  • Verify rollback options for agents, policies, and account connections.
  • Confirm support and incident owners are on call for launch.
Production readiness is not just setup. It also means having a controlled first 24 to 72 hours.
  • Announce launch scope internally.
  • Enable only the approved production agents and policy set.
  • Monitor the first user sessions closely.
  • Review unexpected authorization denials or tool failures quickly.
  • Confirm connected accounts and OAuth redirects continue to succeed after launch.
  • Capture support questions and update docs or onboarding instructions immediately.
  • Review the first revision and access-control changes after go-live.

​
Minimum Go-Live Bar

If you need a simple launch gate, do not go live until all of the following are true:
  • At least one production MCP server is connected and tested
  • At least one production agent is registered and configured
  • Required user accounts are connected successfully
  • Production policies are validated and active
  • Policy testing has confirmed both expected allows and expected denies
  • Admins can use the policy summary view and enforcement logs to verify live behavior
  • At least one target AI client has been tested end to end
  • Network allowlisting is complete for any custom/internal MCP servers
  • Your support and rollback owners are identified
Once every item above is checked off, your Barndoor environment is in a strong position for controlled production rollout.