When segregation of duties is ignored and a JSON schema is altered without proper oversight, downstream services can break, data quality degrades, and compliance audits stumble.
JSON schema is the contract that validates incoming data for APIs, event streams, and configuration files. A single change, adding a required field, loosening a pattern, or renaming a property, can ripple through dozens of microservices, cause silent data loss, or trigger costly rollbacks.
Most teams protect the schema repository with static credentials or service‑account tokens and rely on an identity provider to decide who can log in. The identity check tells the system *who* is making the request, but it does not decide *what* that identity is allowed to do once the connection is established.
Segregation of duties means that no single person or automated identity can both create a new schema version and push it to production without an independent check. Without a dedicated enforcement point, the same token that reads a schema can also write it, making it easy for a developer, a compromised CI job, or a malicious script to bypass policy.
The missing piece is a control surface that sits between the authenticated identity and the schema store, where every write request can be examined, approved, recorded, or blocked. Only a data‑path gateway can provide that level of assurance.
Why segregation of duties matters for JSON schema
Segregation of duties reduces the risk of accidental or intentional schema drift. By separating the roles of author (who drafts a change) and approver (who validates the impact), organizations gain:
- Clear accountability – audit trails show exactly which identity proposed a change and which senior engineer sign‑offed it.
- Reduced blast radius – a change that introduces an incompatible type can be halted before it reaches production.
- Compliance evidence – regulators often require proof that critical data contracts are controlled by at least two independent parties.
In practice, teams that rely solely on Git permissions or CI pipelines often find that a single privileged account can merge a change and trigger a deployment in one step, violating the very principle of segregation of duties.
The missing enforcement layer
Even with strong identity management (OIDC, SAML, MFA), the request still travels directly to the schema registry. The gateway that the request passes through is the only place where policy can be enforced. If that gateway is absent, the following gaps appear:
- No real‑time approval workflow – a change is applied the moment a push succeeds.
- No command‑level audit – logs only show a generic "git push" without the exact JSON diff.
- No ability to block dangerous operations – a malformed schema can be written without validation.
These gaps mean that the setup provides authentication but not authorization, leaving segregation of duties incomplete.
hoop.dev as the data‑path gateway
hoop.dev is built to sit in the data path between identities and infrastructure targets. When a user or automation agent connects to a JSON schema store through hoop.dev, the gateway can:
- Verify the caller’s OIDC token and extract group membership before any request reaches the repository.
- Require a just‑in‑time approval step for any write operation, routing the request to a designated reviewer.
- Record the full request and response, creating an audit trail that ties the change to a specific identity and approval event.
- Block schema updates that violate predefined guardrails, such as adding required fields without a version bump.
Because hoop.dev handles the connection at the protocol layer, the enforcement outcomes exist only because the gateway is present. Removing hoop.dev would return the system to the insecure state described earlier.
Deploying hoop.dev is straightforward: a Docker Compose quick‑start brings up the gateway, an agent runs next to the schema store, and OIDC configuration points the gateway at your identity provider. The getting‑started guide walks through the steps, while the learn section explains how to configure approval policies and audit retention.
FAQ
Q: Does hoop.dev replace my existing Git permissions?
A: No. hoop.dev complements repository permissions by adding a runtime enforcement layer. Git still controls who can push, but every push that modifies a JSON schema must pass through hoop.dev’s approval workflow.
Q: Can I use hoop.dev with existing CI/CD pipelines?
A: Yes. CI jobs can authenticate via OIDC, then invoke the schema store through hoop.dev. The gateway will enforce the same segregation of duties policies as interactive users.
Q: Is the audit data stored securely?
A: hoop.dev records each session in a secure audit store that is separate from the target system, providing the evidence needed for compliance audits.
By placing a policy‑enforcing gateway directly in the data path, organizations can finally achieve true segregation of duties for JSON schema management.
Explore the source code, contribute improvements, and see how the gateway fits into your stack on GitHub.
