Every vendor pitch deck in this industry has the same slide. It shows two logos connected by a smug little bidirectional arrow labeled “seamless real-time sync.” Nobody in the room asks the only question that matters: what happens the day one side of that arrow gets popped? Nobody, because “seamless” sells and “blast radius” doesn’t. We’ve watched this pattern turn a single compromised MSSP tenant into a multi-customer breach often enough that we built our own sharing model specifically to refuse to play along.
So let’s talk about how HEFAISTOS moves data between organizations and instances, because it is deliberately, aggressively boring — and boring is the point.
The Industry’s Favorite Lie: “Sync” Means Safe
“Federated,” “integrated,” “connected ecosystem” — these words get thrown around detection and SOAR tooling like they’re free. In practice, a huge share of “integrations” in this space are OAuth grants with way too much scope, API keys with no expiry, and a write path back into your environment that nobody threat-modeled because the demo worked and the roadmap had a deadline. You end up with a partner’s helpdesk intern effectively holding write access to your detection content because someone needed “real-time collaboration” three years ago and never revisited it. That’s not integration. That’s an unmonitored attack path with a marketing budget.
We refused to build that. Not because we’re purists, but because we’ve spent enough time in identity and attack-path work to know exactly how that story ends: lateral movement through the vendor you trusted, not the one you were watching.
What Sharing Actually Is in HEFAISTOS: Read-Only PULL, Nothing Else
The current instance-to-instance sharing mechanism in HEFAISTOS is explicit about what it is not. It’s not live co-authoring. It’s not bidirectional sync. It’s not a write-through channel into someone else’s environment. The backend literally returns a mode field that says PULL_READ_ONLY, and the export endpoint is GET-only. There is no remote mutation path. Full stop.
One instance exposes eligible content through scope-limited, API-key-authenticated endpoints. Another instance — configured as a trusted peer — pulls that content on a schedule or on demand, and imports/updates its own local copies. The remote side never gets touched. Your engineering objects stay yours; the receiving org gets a local import, not a live window into your production tenant.
If that sounds unglamorous, good. Glamorous sharing models are how you end up explaining a breach to a board that thought “sync” was a feature, not a liability.
Default-Deny, Because “Everything Is Shareable” Is How You Get Owned
Here’s the part every “seamless integration” platform skips: export eligibility in HEFAISTOS is default-deny. An object doesn’t become remotely pullable just because it exists. A Workbench has to be DEPLOYED and explicitly flagged allow_remote_pull=True. Rules only travel when tied to an eligible deployed playbook. ACH analyses must be FINISHED and separately opted in. ADVOPS reports need the same explicit consent flag.
That’s a deliberate double gate: lifecycle maturity plus explicit remote-exposure consent, checked per object, not toggled once at the org level and forgotten. Nobody accidentally ships a draft detection — or worse, a half-finished ACH analysis full of half-baked hypotheses about an active intrusion — to a partner org because someone fat-fingered a global “share everything” switch. That switch doesn’t exist.
Scopes and Tags: Because Not All Trust Is Equal
We also don’t pretend that trusting a peer with your Rules is the same as trusting them with your ACH analyses or your AdvOps output. Sharing scopes (WORKBENCH, RULES, ACH, ADVOPS, ALL) let an org hand over exactly the content class it means to, and inbound share keys can additionally enforce tag filters so only a specific subset of eligible objects actually leaves the building. Scope answers “what kind of object.” Tags answer “which of those, specifically.” Neither is decorative — both are checked on the inbound key and the pull operation, not just documented and ignored like half the compliance matrices we’ve seen.
Two Different Problems, Not One Blurry One: Instance Sharing vs HEF/HEX
We also keep a distinction that most vendors happily blur because blurring sounds more impressive in a sales call: instance sharing (the read-only PULL API for repeated, controlled synchronization between trusted peers) is not the same mechanism as HEF/HEX export-import (portable artifact bundles for migration, backup, and one-time transport). One is a standing, scoped, auditable trust relationship between two live instances. The other is a file you hand someone once. Conflating them is exactly how “we exported a backup” quietly becomes “we granted a standing remote integration,” which is how shadow trust relationships accumulate in every environment we’ve ever done attack-path work in.
Same-Tenant First, Federation Second
The primary use case is exactly what you’d expect from a platform built for MSSPs and multi-org enterprises: sharing between organizations under one entity, so a parent security team can push mature, deployed detection content down to subsidiary or client orgs without those orgs freely wandering into each other’s workspace. A user is scoped to one organization — no default cross-org roaming — with a narrow, explicit exception for HR-style user-management roles that legitimately need multi-org visibility for account administration, not detection content. Cross-instance sharing between genuinely unrelated HEFAISTOS deployments is also possible, because closed gardens don’t serve anyone either, but it rides the same conservative, scope-limited, default-deny rails as everything else. No special-case backdoor for “trusted community partners” that quietly bypasses the model the moment it’s inconvenient.
Deployed Does Not Mean Good — We’re Not Claiming Magic Here
One more thing worth saying plainly, because it’s tempting to oversell your own architecture: an object being eligible for export doesn’t mean the export is useful. A deployed Workbench with allow_remote_pull=True can still be operationally hollow if nobody populated the response playbook or the false-positive notes. Projection and sharing move content around correctly. They don’t retroactively make sloppy engineering good. That’s still on the humans, same as always.
The Point
Integration hype has spent a decade selling “seamless” as a virtue and treating “read-only” as a limitation to apologize for. We think that’s backwards. Every write path you don’t build is an attack path you don’t have to defend. Every default-deny gate is a compromised-partner scenario that stops at the boundary instead of walking straight into your detection engineering. We’d rather ship a sharing model that’s boring, auditable, and default-deny than one that demos well and turns your nicest MSSP relationship into someone else’s initial access vector.
Good riddance to magic federation.
Featured image generated using Artificial Intelligence (EU AI Act transparency notice).