Join our Newsletter — 33% off our NHI Course

JSON-RPC

JSON-RPC is a remote procedure call protocol that uses JSON to carry requests and responses between client and server. In practice, it sends method names, parameters, and identifiers through a single endpoint, which makes security controls depend on body inspection, method authorization, and strict validation rather than URL structure.

Expanded Definition

JSON-RPC is an application-layer procedure call pattern that packages a method name, parameters, and request identifier into JSON, then returns either a result or an error object. Because requests usually travel through a single HTTP endpoint, security teams cannot rely on path-based filtering or route-level trust boundaries. Instead, they must inspect message bodies, validate schema, and authorize each method explicitly.

Definitions vary across vendors when JSON-RPC is used alongside webhooks, gateway mediation, or agent tool execution, but the core idea remains consistent: the transport is not the control plane. For identity and access decisions, the important question is who may invoke which method, with what parameters, and under what assurance. That makes JSON-RPC relevant wherever service-to-service calls, privileged automation, or agentic workflows need tight authorization and auditability. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces governance, access control, and monitoring as baseline security outcomes rather than assuming the protocol itself provides protection.

The most common misapplication is treating JSON-RPC as safe because it uses a single authenticated endpoint, which occurs when teams fail to inspect the method name and parameters before execution.

Examples and Use Cases

Implementing JSON-RPC rigorously often introduces extra validation and authorization overhead, requiring organisations to balance development speed against stronger request-level control.

  • A privileged automation platform exposes administrative methods such as create_user or rotate_secret, and each method is individually authorized before execution.
  • An internal developer portal uses JSON-RPC for backend tooling, with schema validation preventing unexpected parameters from reaching sensitive operations.
  • An AI agent invokes business functions through JSON-RPC, and the service enforces allowlisted methods so the agent cannot request unrestricted actions.
  • A partner integration submits reconciliation requests over JSON-RPC, with response handling and error codes logged for traceability and incident review.
  • A security gateway fronts a legacy service, translating requests while inspecting the body for disallowed methods or malformed payloads.

In service mesh or API gateway environments, JSON-RPC is often paired with controls from the NIST Cybersecurity Framework 2.0 to support consistent access control and event logging. It is also commonly discussed in relation to the RFC 8259 JSON data interchange format, because payload correctness and strict parsing are foundational to safe operation.

Why It Matters for Security Teams

JSON-RPC matters because it shifts security responsibility away from URL structure and into message-level inspection, which is easier to overlook and harder to retrofit. If a team assumes the endpoint boundary is enough, an attacker or over-privileged automation client may call sensitive methods simply by changing the request body. That creates risk across confidentiality, integrity, and availability, especially when methods expose administrative functions, secrets handling, or agent tool access.

This becomes especially important in environments using non-human identities and autonomous agents, where the caller may be a workload, token, or software agent rather than a person. Method-level authorization, input validation, strong authentication, and logging all need to be aligned so the protocol cannot be abused as a hidden control channel. The NIST Cybersecurity Framework 2.0 remains the most practical governance lens for this because it maps cleanly to access control, monitoring, and response expectations.

Organisations typically encounter JSON-RPC risk only after an exposed method is abused or a trusted integration performs an action it was never meant to trigger, at which point JSON-RPC becomes operationally unavoidable to address.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 PR.AC-4 JSON-RPC security depends on method-level authorization and least privilege.
NIST AI RMF AI systems using JSON-RPC need governance over tool calls and misuse pathways.
NIST SP 800-63 IAL2 Assurance guidance helps when JSON-RPC carries identity-sensitive workflows.
OWASP Agentic AI Top 10 Agent tool use through RPC interfaces is a common abuse path in agentic systems.

Use appropriate identity assurance before allowing JSON-RPC actions that affect user records or access.