Many teams think IAM can be tacked onto any JSON document without a formal schema, but that assumption quickly leads to inconsistent permissions and hidden security gaps.
Why teams fall into the unstructured IAM trap
In practice, engineers often store permission maps in loose JSON files that grow organically. A developer adds a new action, another adds a resource identifier, and soon the file contains a mixture of camelCase, snake_case, and free‑form strings. Validation is performed only when a service crashes or an unexpected privilege escalation is discovered. The result is over‑permissive roles, duplicated entries, and a maintenance burden that scales with the number of services.
Because the JSON is never validated against a contract, a typo such as readr instead of read silently grants no access, while a missing effect field may default to an allow‑all rule in the consuming service. Without a schema, static analysis tools cannot catch these errors, and auditors have no reliable artifact to review.
The real starting state for many organizations
Typical deployments look like this: a shared repository holds a permissions.json file that is edited by multiple engineers. The file is checked into version control, but the CI pipeline does not enforce structural correctness. When a new service is spun up, the ops team copies the file, updates a few entries, and points the service at the same JSON blob. Access decisions are made by the service code itself, which reads the raw JSON at runtime. No gateway sits between the request and the resource, so there is no place to enforce a policy, no audit log of who queried which permission, and no way to mask sensitive identifiers before they leave the service.
In this unsanitized state, the setup determines who can request a change (the Setup layer), but the enforcement never happens. The request travels directly to the target database, Kubernetes API, or SSH daemon, and any mistake in the JSON is executed without review.
What a JSON schema adds – and what it still leaves open
A JSON schema can describe the exact shape of an IAM document: required fields, allowed values for actions, regular‑expression patterns for resource ARNs, and enum constraints for effect types. By validating every change against this schema, teams gain early feedback, prevent malformed policies, and create a single source of truth that can be versioned and reviewed.
However, validation alone does not stop a malicious or accidental request from reaching the target. The schema lives in the repository, but the runtime path still lacks a control point. The request still bypasses any approval workflow, there is no session recording, and no inline masking of sensitive identifiers such as account IDs. In other words, the precondition we fix is structural correctness; the gap that remains is the absence of a data‑path enforcement layer.
Introducing a data‑path gateway for IAM
To close the gap, the enforcement point must sit between the identity that initiates a request and the infrastructure that fulfills it. That gateway can evaluate the incoming request against the JSON schema, apply just‑in‑time approvals, mask sensitive fields in the response, and record the entire session for later replay.
hoop.dev provides exactly that. It is a Layer 7 gateway that proxies connections to databases, Kubernetes clusters, SSH endpoints, and HTTP services. By placing hoop.dev in the data path, every IAM‑related request is forced through a single control surface where policy can be enforced in real time.