Why the Handshake Pattern Beats Centralized Permissions

Most platforms solve cross-system access with a central service account that has permissions everywhere. Simple to set up. Easy to manage.

Also a fundamental security violation.

God-mode service accounts break least privilege, separation of duties, and blast radius containment. Compromise that account and you compromise everything. Yet teams build this way constantly because it’s the path of least resistance.

There’s a better approach.

Two Anti-Patterns Worth Naming

Before the solution, it helps to be clear on what we’re moving away from.

Centralising everything. The instinct is to move all permission management to the central platform. But as your platform grows, you become the bottleneck. Every governance decision flows through you. Every permission change requires your team. Every compliance question lands on your desk.

The god-mode service account. Single point of compromise — lose the account, lose everything. And when every action comes from the same account, how do you know why an action was taken or who actually triggered it? Auditing becomes a nightmare.

The Handshake Pattern

Instead of a central account with permissions everywhere, build a system where components negotiate directly.

The key insight: the central system never has permissions in the source systems. It asks the source systems to manage their own permissions. Source systems maintain full control and governance.

Here’s how it works in practice:

Granting access:

1. Central system receives a request: “Grant access to resource X in system Y”
2. Central system creates a record of this intent — the why
3. Central system sends a request to the source system: “Please provision access to resource X for identity Z”
4. Source system provisions access using its own local permissions
5. Source system confirms: “Access granted”

Revoking access follows the same flow in reverse. The central system sends the request; the source system executes it.

Why It Works

Ownership stays distributed. Teams maintain control of their resources. Their governance policies stay intact. They’re not handing control to a central team or trusting a god account they didn’t provision.

Security boundaries are clear. No external service account has broad access. The only permissions that exist are the ones explicitly granted when teams choose to share resources.

Governance is local. When someone asks “who has access to our resources?”, teams look at their own system permissions. They don’t have to trust external logs or hope a central team configured things correctly.

Complexity scales horizontally. With a god account, the central system needs to understand every source system’s permission model — complexity centralises and the central system becomes unmaintainable. With the handshake pattern, the central system just needs to know how to ask for permissions.

What Auditors Actually Want

Auditors don’t just want to see that access was removed. They want provable intent and automated enforcement. The handshake pattern gives them both:

• Clear intent: The access request is a record — on this date, this request was made for this resource
• Automated enforcement: The source system fulfils the request automatically — no manual steps, no human-in-the-loop errors
• Provable execution: The source system confirms back — on this date, this resource was provisioned

This matches how manual governance works, but at software speeds.

Where This Applies

This isn’t specific to data platforms. The principle applies anywhere you have cross-system access:

• Service mesh authorisation: Services negotiate with each other using mutual TLS and policy engines rather than trusting a central authority
• Multi-tenant platforms: Tenants manage their own permissions; the platform doesn’t have god-mode access to tenant resources
• Cross-team resource sharing: Teams maintain ownership; central systems coordinate rather than control
• Marketplace models: Providers control what they share; the marketplace facilitates discovery and requests without taking ownership

The Implementation Reality

The instinct when building platforms is to centralise control. It feels simpler. It’s easier to reason about in the short term. But it creates security vulnerabilities, scaling bottlenecks, and governance nightmares.

Yes, the handshake pattern requires more work upfront. Each source system needs to implement the handshake — they need to respond to provision and revocation requests. That’s a real cost.

But it’s a one-time setup, and the benefits compound: better security, clearer governance, better compliance, and complexity that scales horizontally instead of collapsing into a single point of failure.

Teams initially resist because it seems like extra work compared to handing everything to a central system. What changes their mind is understanding the real alternatives: give up control entirely, or trust an external god account in their system.

Once teams see those are the actual choices, the handshake pattern becomes obvious.

Don’t build systems that control everything. Build systems that delegate and negotiate.