# Production Guardrails Building an AI agent is easy. Building one that safely interacts with production systems is much harder. Unlike traditional applications, AI agents make decisions dynamically. A single prompt can trigger multiple API calls, execute workflows, or interact with critical business systems. Without proper safeguards, mistakes can quickly become production incidents. Swytchcode provides multiple layers of protection to help you build reliable AI applications. This guide explains the recommended practices for deploying AI agents in production. --- ## Defense in Depth No single safeguard is enough. Instead, combine multiple layers of protection. ```text User Prompt │ ▼ AI Agent │ ▼ Trusted Tools (tooling.json) │ ▼ Policy Validation (policies.json) │ ▼ Execution Controls (manifest.json) │ ▼ Authentication │ ▼ Provider API ``` If one layer fails, the remaining layers continue protecting your application. --- ## Principle of Least Privilege Only expose the tools your application actually needs. For example, if an AI assistant only creates GitHub issues, it should not also have permission to: - Delete repositories - Manage organization members - Create deployments - Modify repository settings Every additional capability increases the potential impact of an unexpected or incorrect request. Keep your trusted tool list as small as possible. --- ## Separate Development and Production Never use production resources during development. Instead: ```text Development │ ▼ Sandbox APIs │ ▼ Testing │ ▼ Production ``` Use sandbox endpoints whenever they are available. Before switching to production, verify that: - Policies have been validated. - Authentication is configured correctly. - Expected requests behave as intended. --- ## Protect Destructive Operations Operations that modify or delete data deserve additional protection. Examples include: - Deleting repositories - Canceling subscriptions - Refunding payments - Revoking user access - Removing infrastructure - Deleting databases Consider blocking these operations entirely in production unless they are explicitly required: ```json { "id": "block-database-reset", "target": ["postgres.database.reset"], "when": { "field": "database", "operator": "exists" }, "action": { "type": "POLICY_BLOCKED", "message": "Database resets are disabled in production." } } ``` When possible, separate read-only tools from write operations - only enable the write method in `tooling.json` for the environments and agents that genuinely need it. --- ## Validate Every Request Do not assume that generated requests are correct. Always validate important request fields before execution. Examples include: - Payment amounts - Email addresses - Resource identifiers - Organization names - Deployment environments - Regions Reject invalid requests before they reach the provider. --- ## Use Idempotency for Mutating Operations Network failures happen. Retries happen. Without idempotency, the same request can execute more than once. ```text Create Payment │ ▼ Request Times Out │ ▼ Automatic Retry │ ▼ Duplicate Payment ``` With idempotency enabled: ```text Create Payment │ ▼ Request Times Out │ ▼ Retry │ ▼ Existing Operation Returned ``` For APIs that support idempotency, enable it whenever requests create, modify, or delete resources. --- ## Configure Retries Carefully Retries improve reliability, but they should be used selectively. Good retry candidates include: - Temporary server failures - Network interruptions - Rate limiting - Service unavailable responses Avoid retrying requests that fail because of invalid input or authorization issues. A retry should only happen when another attempt has a reasonable chance of succeeding. --- ## Limit Concurrency AI agents often execute multiple operations simultaneously. Without limits, this can overwhelm downstream services. Instead of allowing unlimited parallel requests: ```text 100 Parallel Requests ``` Use reasonable concurrency limits based on the provider's recommendations. This reduces: - Rate limiting - Resource exhaustion - Unexpected API failures --- ## Secure Authentication Treat API credentials as production secrets. Never: - Hardcode API keys - Commit credentials to Git repositories - Embed secrets in prompts - Store secrets in source code Instead: - Use environment variables. - Use OAuth where supported. - Rotate credentials regularly. - Grant only the minimum required permissions. --- ## Restrict Network Access Whenever possible, limit outbound requests to trusted providers. Instead of allowing requests to any destination, configure an allowlist of expected hosts. For example: - `api.stripe.com` - `api.github.com` - `api.slack.com` Restricting network access helps prevent accidental or unauthorized communication with unexpected endpoints. --- ## Pin Integration Versions Always use pinned integration versions. Avoid automatically upgrading integrations in production without testing. Version pinning provides: - Reproducible behavior - Predictable request formats - Easier debugging - Safer deployments Review new integration versions before adopting them. --- ## Test Before Deploying Every change should follow a predictable deployment process. ```text Update Configuration │ ▼ Validate Policies │ ▼ Run Sandbox Tests │ ▼ Review Results │ ▼ Deploy to Production ``` Testing before deployment reduces the likelihood of production incidents and makes behavior easier to verify. In command form, that pipeline is: ```bash swy policy validate # catch structural errors in policies.json swy exec --dry-run # validate a specific request without executing it # review results, then deploy ``` --- ## Monitor and Audit Production systems should be observable. Swytchcode keeps a local audit trail under `~/.swytchcode/audit/` that you can query directly, without needing Cloud Sync enabled: ```bash swy audit stats # total runs, success rate, last run, top provider swy audit network -n 20 # recent outbound calls: host, method, status, duration swy audit policy -n 20 # recent policy-violation log entries swy doctor # tooling, bundles, auth, permissions, secrets ``` Regularly review: - Enabled tools (`swy list tooling`) and active integrations (`swy list integrations`) - Policy changes - diff `policies.json` in code review like any other config file - Failed executions and their exit codes (see [Troubleshooting](/reference/troubleshooting/)) - Policy violations via `swy audit policy` - this is a read-only history of what got blocked, distinct from `swy policy list`, which shows the rules themselves - Authentication failures - `swy whoami` and `swy auth status` show current auth state; failing calls also show up in `swy audit network` Treat changes to policies and integrations with the same level of review as application code. --- ## Production Checklist Before deploying an AI agent, verify the following: - [ ] Only required tools are enabled (`swy list tooling`). - [ ] Policies have been validated (`swy policy validate`). - [ ] Sandbox testing has been completed. - [ ] Production credentials are configured securely (`swy auth status`, `swy doctor`). - [ ] Integration versions are pinned. - [ ] Idempotency is enabled for mutating operations. - [ ] Retry behavior has been reviewed. - [ ] Concurrency limits have been configured. - [ ] Network access is restricted where possible (`swy doctor --network`). - [ ] Secrets are managed securely. - [ ] Policy and configuration changes have been reviewed. --- ## Key Takeaways A production-ready AI agent should be: - **Least-privileged** - Only the required capabilities are available. - **Policy-driven** - Every request is validated before execution. - **Reliable** - Retries, timeouts, and idempotency are configured appropriately. - **Observable** - Behavior can be monitored and audited. - **Predictable** - Configuration is version-controlled and reproducible. By combining trusted tools, policy validation, execution controls, and secure authentication, you can confidently deploy AI agents that interact with real-world APIs while minimizing operational risk. --- ## Next steps - [Policies overview](https://docs.swytchcode.com/policies/overview/) - The policy engine that decides what an agent can do, when, and how. - [Policy Rules](https://docs.swytchcode.com/policies/policy-rules/) - Write custom policies using conditions, operators, and actions. - [Best Practices](https://docs.swytchcode.com/policies/best-practices/) - Recommendations for maintainable, predictable, secure policy configurations. - [manifest.json](https://docs.swytchcode.com/configuration/manifest-json/) - Configure endpoints, retries, timeouts, and idempotency for each integration.