A unary RPC is a request-response interaction where one client call receives one server reply. It is the standard choice for discrete actions such as creating an item, retrieving a record, or submitting an update. Unary methods are simple to reason about and map well to CRUD-style operations.
Unary RPC in distributed systems
Unary RPC is the simplest remote call pattern: a client sends one request and receives one response. That makes it the default fit for discrete operations such as creating a record, fetching a resource, or submitting a single update.
Because the interaction is request-response, the protocol surface is usually easier to reason about than streaming or bidirectional patterns. The trade-off is that each call still crosses a network boundary, so latency, retries, timeouts, and serialization overhead all matter even when the business operation looks straightforward.
Unary RPCs also tend to mirror CRUD-style application design. That is useful when the system needs clear success or failure semantics for one action at a time, especially for APIs that must stay predictable for clients, load balancers, and observability tools.
How unary RPC differs from streaming patterns
The main difference is interaction shape. Unary RPC finishes after a single round trip, while client streaming, server streaming, and bidirectional streaming keep the connection open for multiple messages. Unary therefore favors small, self-contained operations, whereas streaming better suits long-running transfers, event feeds, or incremental processing.
This matters because the choice changes operational behaviour. Unary calls are usually simpler to retry safely when the request is idempotent, but they can become inefficient for chatty workflows that need many back-and-forth exchanges. Streaming can reduce overhead, but it also introduces more state, flow control concerns, and lifecycle complexity.
In practice, unary RPC is often the right baseline when a service boundary represents a clear business action. If the interaction starts to feel like a loop of repeated unary calls, that is usually a sign the interface may be carrying too much conversational work for a request-response model.
Where security and reliability considerations show up
Unary RPC is not inherently risky, but the simplicity can hide real exposure. Each call still depends on authentication, authorization, input validation, transport protection, and careful handling of retries and idempotency. A clean request-response shape does not remove the need to secure the endpoint or the data it carries.
One common failure mode is assuming that a "single call" is automatically low risk. In reality, a high-value unary method can still be abused for enumeration, injection, excessive invocation, or abuse of business logic if the API is poorly governed. Strong API design and rate controls remain important even for the most basic RPC methods.
For API-specific defensive guidance, the OWASP API Security Top 10 is the most relevant external reference in the supplied set, because unary RPC often exposes the same authorization and abuse conditions seen in general APIs. For broad control coverage, NIST SP 800-53 Rev 5 Security and Privacy Controls maps well to access control, auditability, and system integrity expectations for RPC endpoints.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access Control Management | Unary RPC endpoints depend on controlling who can invoke each action. |
| PR.DS-1 — Data-at-Rest Protection | Unary RPC often carries records or updates that need protection in transit and storage. | |
| Recommendation — Apply PR.AC-4 to enforce least-privilege access on RPC methods. Protect RPC payload data according to PR.DS-1 where sensitive content is exchanged. | ||
| CIS Controls v8 | 6 — Access Control Management | Unary RPCs are API access paths that need account and privilege governance. |
| 12 — Network Infrastructure Management | RPC traffic depends on secure service exposure and boundary configuration. | |
| Recommendation — Use CIS Control 6 to restrict and review who can invoke each RPC method. Apply CIS Control 12 to harden the network paths that expose unary RPC services. | ||
| OWASP Agentic AI Top 10 | 4 — Access Control and Authorization | Unary RPC is a request-response API pattern that can fail when authorization is weak. |
| 8 — Input Validation and Output Encoding | Unary RPC request messages still need strict validation before processing. | |
| 9 — Secure Communication and Session Management | Unary RPC relies on authenticated, protected transport for each request-response exchange. | |
| Recommendation — Enforce method-level authorization on every unary RPC call. Validate unary RPC inputs before execution and reject malformed requests early. Use secure transport and session controls for unary RPC traffic. | ||
Practitioner Guidance
Why practitioners should care: Unary RPC is often the control point where an application exposes its most routine, and therefore most widely used, business actions. That means the method definition itself should be treated as part of the service’s security boundary, not just an implementation detail.
Common misunderstanding: Teams sometimes assume unary methods are "safe by default" because they are small and simple. Simplicity helps readability, but it does not replace endpoint-level authorization, abuse resistance, or clear idempotency rules for retries.
Practitioner takeaway: Design unary methods so each one does one business action cleanly, then make the request contract explicit about identity checks, retry behaviour, and error semantics.
Risk and Threat Considerations
Unary RPC becomes risky when it is used for sensitive operations without strong access control or when repeated calls can be automated at scale. The most common exposure is not the request-response pattern itself, but the fact that a very small surface can still become a high-frequency abuse channel.
Failure mechanism: Weak authorization, missing input validation, or unsafe retry handling can let attackers enumerate records, submit unauthorized actions, or amplify load through repeated calls that look legitimate at the protocol level.
Impact: The result can be data exposure, integrity loss, noisy abuse of business workflows, and service degradation, especially when unary methods are tied to account actions, record access, or payment-like state changes.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
