Solving back-office AI access for a recruiting company

How Strato, a permissioned MCP platform, let a non-technical team use Claude against their real systems, with audit and access control built in.

The problem

I worked with a recruiting company that was just starting their AI transformation journey. The team had Claude subscriptions set up but were limited in its impact, as Claude didn’t have access to the critical back-office systems that made their business move.

The team’s workaround was pasting spreadsheets and screenshots into chat. That workaround became its own job, and the efficiency gain turned into an efficiency tax.

The approach

Version 1 · Direct MCP servers

The first build I implemented wrapped each back-office API as an MCP server connected directly to the founder’s Claude. It validated that giving Claude access to real systems unlocked real workflows: reports, business check-ins, cross-system analysis that previously required pulling data from three places.

This empowered the founder’s personal workflow, but didn’t scale to the rest of the team. Diving deeper, I found three constraints preventing this from delivering impact to the whole team:

• Permissions. Different roles need different scopes on the same service. An invoice reconciler needs read access to invoices and write access to specific fields, but should not be able to send invoices out. Managing that per employee, per service, inside Claude’s connector settings was unworkable.
• Auth reliability. OAuth for Claude connectors is fragile, especially in workflows that span multiple services. A single dropped connection breaks the chain. Auth needed to be managed outside the model context.
• Auditability. Write operations require a record of what changed, by whom, and when, plus the ability to revoke access quickly if something looks wrong.

Version 2 · Strato

Strato is a single platform that sits between Claude and the company’s back-office systems and centralizes the four operating concerns the direct-connector approach couldn’t handle.

• Per-employee permissioning. The admin creates a login for each employee and granularly defines tool access and scopes per user.
• Connection management. Strato manages the connection to each underlying service through whatever auth method that service requires (OAuth, API keys, custom flows) and maintains the connection state outside of Claude.
• Tool inventory. Every tool exposed by each connection is visible to the admin in one place.
• Custom MCP links. Each employee receives a single MCP link to add to their Claude setup. That link exposes exactly the tools and scopes the admin has assigned, with auth and permissions handled outside Claude.

Every action through the platform is logged. Admins have a full audit trail per employee and can revoke access at the user or tool level.

The result

Strato is deployed and in active use. The founder runs reporting, business check-ins, and cross-system analysis through the platform that previously required pulling data from three separate tools. Permissions, audit, and revoke are all live and working in production.

Why this matters

Most companies adopting AI right now hit the same wall. A power user gets significant leverage from Claude on personal workflows. Extending that leverage to a team requires permissions, audit, and auth reliability that don’t exist out of the box. Those aren’t optional features at scale. Without them, AI stays a power-user tool instead of a team capability.

Where this goes next

1. Generalizing the platform. The architecture is not specific to one company. Most teams with non-technical employees and enterprise back-office tools have the same problem. Strato could become a standalone product.
2. Active audit instead of passive logging. The current audit trail is a passive log. A next version would flag anomalous activity in real time and propose revokes automatically.
3. Closing the adoption gap. Day-to-day usage is still concentrated with the founder. The technical platform is ready, but lower-level employees who haven’t used Claude as a primary work interface need onboarding, suggested workflows, and templates to build the habit. The harder problem here is behavioral, not technical.