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.

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:

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:

{
  "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.

Create Payment
      │
      ▼
Request Times Out
      │
      ▼
Automatic Retry
      │
      ▼
Duplicate Payment

With idempotency enabled:

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:

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.

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:

swy policy validate                        # catch structural errors in policies.json
swy exec <canonical_id> --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:

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)
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:

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

The policy engine that decides what an agent can do, when, and how.

Policy Rules

Write custom policies using conditions, operators, and actions.

Best Practices

Recommendations for maintainable, predictable, secure policy configurations.

manifest.json

Configure endpoints, retries, timeouts, and idempotency for each integration.