How to Migrate from Shared Cards to Scoped Agent Delegation (Without Downtime)

_Last updated: 2026-06-10_

If your AI agents are running on a shared corporate card right now, that's fixable, and you don't have to take anything offline to fix it. The migration from a shared card to scoped agent delegation follows a five-step sequence: audit current exposure, map agents to scopes, cut over workflow by workflow, decommission the shared card, and verify audit coverage. Done carefully, it takes a few days to a few weeks depending on how many agents you're running.

Key takeaways

• Running multiple agents on a shared card means any single compromised or misbehaving agent can spend up to the full card limit. There's no per-agent blast radius boundary.
• Migration doesn't require a big-bang cutover: you transition one workflow at a time, keep the shared card live until all workflows have moved, then decommission it.
• The audit step is not optional. You need a clear picture of what's currently spending on the shared card before you can assign accurate scopes to the replacement cards.
• Scope assignment should reflect minimum necessary access, not maximum convenience. Agents don't need access to merchant categories they've never used.
• After decommissioning, verify that the shared card number is not stored anywhere: config files, environment variables, secrets managers, hardcoded strings.

---

Step 1: Audit current exposure

Before you change anything, you need to understand what you currently have.

Pull the last 90 days of transactions on the shared card. You're looking for three things.

Start with attribution: which agents are spending what. Cross-reference transaction IDs against agent logs. If you can't attribute existing charges to specific agents, you don't have enough visibility to manage the system safely regardless of card structure.

Then sort by agent and MCC to see which merchants and categories each agent uses. An agent that has only ever charged SaaS subscriptions (MCC 7372) and software purchases (MCC 5045) does not need access to travel, restaurants, or general retail.

Finally, pull actual spend patterns: daily and monthly totals per agent, average transaction size, peak frequency. These set realistic velocity rules and ceilings. Use the data; don't guess.

Record this in a structured document. You'll reference it throughout the migration.

---

Step 2: Map agents to scopes

For each agent, define its minimum necessary scope:

• Merchant categories: list the MCCs the agent has actually used in the past 90 days. Exclude everything else. Unknown categories can be added later with a deliberate update.
• Spend ceilings: set the monthly ceiling at roughly 120-150% of typical monthly spend. Enough headroom, tight enough to bound a runaway. Set a daily ceiling too, at roughly 2-3x average daily spend.
• Merchant-specific rules: for agents with predictable, narrow vendor sets, allowlist by vendor name rather than category. Stricter and cleaner.
• Approval thresholds: any single transaction above 25% of the monthly ceiling is a reasonable starting point for requiring human approval.
• Time windows: if the agent runs on a schedule, encode it. A charge outside operating hours from a business-hours agent is anomalous by definition.

Document the scope before you issue any new cards. The scope is the policy; the card enforces it.

---

Step 3: Cut over workflow by workflow

The approach is parallel running: issue the new scoped card, switch the agent, verify it works, then move to the next one. The shared card stays active until every agent has moved.

For each agent: issue the new virtual card, update the agent's credential configuration (environment variable, secrets manager entry, or config file; keep credentials out of plaintext in repos), run the agent through a test cycle, and mark it migrated after 5-7 clean days on the new card. If a legitimate transaction is declined, the scope is too narrow. Adjust the policy, not the agent behavior.

Order matters. Start with the lowest-spend, lowest-frequency agents. Build confidence before moving high-volume agents that carry the most risk if something goes wrong.

---

Step 4: Decommission the shared card

Once every agent has a verified scoped card and run cleanly for at least one full week, decommission the shared card. "Decommission" means more than canceling.

Suspend first, don't cancel immediately. Run the card suspended for two to four weeks. Any decline against the suspended card tells you someone is still using the old credentials. Find it and migrate it before you cancel.

While it's suspended, search for stored credentials. Grep codebases, scan secrets managers, check environment variables across services and CI/CD pipelines. The shared card number is likely stored in more places than you expect.

Then cancel and invalidate. Once you're confident the number is clear, cancel it. Document the decommission date and the credential search results. Both are useful for any future compliance review or incident investigation.

---

Step 5: Verify audit coverage

Your audit posture should be meaningfully better than before. Confirm it actually is.

Check attribution first. Pull a week of transactions. Can you trace every charge to a specific agent and task? If not, fix the metadata tagging before it becomes a compliance problem.

Then run an enforcement test. Deliberately attempt a transaction that should be blocked: a charge outside the allowed MCC range, or above the daily ceiling. Confirm the decline and confirm it's logged. Don't assume controls work; test them.

Last, check alerts and the trail. Verify anomaly alerts route to live channels and that every transaction, approvals and declines alike, is captured immutably with agent identity, timestamp, merchant, and outcome. Unlogged declines are a blind spot.

---

Migration checklist

• [ ] 90-day transaction audit complete; agent-to-charge attribution documented
• [ ] Scope defined for each agent: MCCs, spend ceiling (daily + monthly), approval threshold, time window
• [ ] New scoped virtual card issued per agent
• [ ] Each agent updated to use new card credentials; old credentials removed from that agent's config
• [ ] Each agent run cleanly for 5-7 days on new card; scope adjustments made if needed
• [ ] All agents marked migrated in internal documentation
• [ ] Shared card suspended
• [ ] Credential search complete across codebases, secrets managers, CI/CD pipelines
• [ ] Zero legitimate traffic confirmed against suspended card over 2-4 weeks
• [ ] Shared card canceled
• [ ] Audit coverage verified: per-agent attribution, policy enforcement tested, alert routing confirmed, audit trail completeness checked

---

Frequently asked questions

How long does migration typically take?

Small deployments (2-5 agents): about a week. Larger ones (20+ agents): two to four weeks. The cutover is fast; the audit and scope definition take the time.

What if an agent tries a merchant that wasn't in the audit?

The authorization is declined and logged. Review it: if the vendor is legitimate, add it to the scope. If it's unexpected, investigate before expanding access.

Do I need to notify vendors when I switch cards?

For subscriptions or recurring charges where the vendor has a card-on-file, yes. Update the payment method during the cutover. It's the most common source of post-migration declined transactions.

Can I skip new cards and just tighten controls on the existing shared card?

Not meaningfully. Controls on a shared card apply identically to every agent using it. You can't have different ceilings or different MCCs per agent on the same card number. Separate cards per agent is a prerequisite for per-agent governance.

---

Ready to issue scoped agent cards and run your first delegation policy? [Shatale is free for publishers right now, get early access and complete your migration in days.](/early-access)