We switched our internal orchestration API from JSON-RPC over HTTP to gRPC for performance. The attack surface changed in ways I didn't fully map initially. It's not just a different transport.

Key differences in exposure:
* The old JSON-RPC endpoint was a single HTTP POST route. Now we have multiple gRPC service methods, each a potential entry point.
* Protobuf parsing happens before your business logic. Fuzzing the old JSON parser was straightforward. Protobufs have their own set of deserialization quirks.
* gRPC often uses HTTP/2. This brings in connection multiplexing, header compression (HPACK) - new vectors to consider.

Generated a list of all services/methods with `grpcui`:
```bash
grpcui -plaintext localhost:9090
```
Found 12 distinct methods across 3 services, two of which I thought were internal-only. The service definitions (.proto files) themselves become critical security docs now.

Immediate concerns:
* **Protobuf parsing edge cases:** Large allocations, recursion depth, map handling.
* **Generated code trust:** Using the stock protoc plugins? Any custom options that alter marshaling/unmarshaling?
* **Channel vs. method-level auth:** We had it at the HTTP route level before. Now need to audit each method's authz.

Anyone else done a threat model on this transition? Specifically:
* Tooling for fuzzing gRPC services (comparable to json-fuzzer).
* Hardening the generated Go structs.
* Audit findings common to gRPC implementations.