Every decrypt of an applicant field goes to the central service holding the key — what becomes countable that a key inside the worker would hide?

## Why a number exists here at all When key material sits inside the process, a decrypt is a function call. It leaves nothing outside that process, costs nothing to repeat, and nothing in the system can tell one decrypt from a million. An attacker who reaches the process gets the key *and* gets silence. Move the operation to a service and the same decrypt becomes a request that has to be authenticated, authorised and answered. That does not make the decrypt safer in itself — the plaintext still comes back to the caller. What it does is create a **fact outside the application**: this caller asked for this operation, under this key, at this time, this many times. That fact is the property this arrangement buys, and it is the one people forget to list when they describe it purely as "the key is somewhere safer". ## What the request path can do with the number - **Cap it.** A per-caller ceiling turns "everything, in minutes" into a bounded number per hour. A claims-intake worker that encrypts a few hundred records a second and decrypts a handful has a profile narrow enough for a ceiling to be meaningful. - **Separate the operations.** A caller that must write but need never read can be allowed to encrypt and refused decrypt entirely, which is a shape you cannot express when the key is a local variable. - **Compare callers.** Two workers doing the same job should have similar operation profiles; the one that does not is a question worth asking. - **Bound a live compromise.** A ceiling does not detect anything, but it limits how much an attacker gets before somebody notices, which is often the only control that actually acts in the first hour. ## What one request still cannot tell you | Question | Answerable from the request itself? | |---|---| | Which caller asked | Yes — that is what authenticated it | | Which key and which operation | Yes, both are named in the request | | How many, how fast, at what hour | Yes, by counting | | Which stored record the ciphertext belonged to | No, unless the caller passes a context value alongside it | | Whether the caller had a legitimate reason | No | | What happened to the plaintext afterwards | No — that is entirely inside the caller | The fourth row matters more than people expect. The service sees an opaque value and an operation, not your database. Where a design lets you attach a context string to each call, passing something that identifies the data class turns an undifferentiated count into something you can reason about; where you do not pass it, you have a volume and nothing else. ## The trap: watching the wrong event The instinct is to alert on failed authentication or refused authorisation at the service. Those catch misconfiguration and clumsy probing. They do **not** catch the case this leaf is about, because an attacker using the worker's own identity **succeeds**. Every one of their decrypts is a clean, authorised, successful call. The signals that catch that are volume against the caller's normal profile, an operation the caller never normally performs, and activity at an hour the workload does not run. The patient case defeats volume too. A caller reading one record every few seconds for a month stays inside any reasonable profile. Bounding that one is a matter of which callers may ask at all and for which key — not of counting. ## The counterfactual, stated plainly It is worth saying out loud what the alternative produces, because it is the comparison an interviewer is listening for: with key material inside the worker, an attacker who reaches the process can decrypt every value they can reach, forever, at any speed, in any environment, and there is no number anywhere that goes up. Not a smaller number — no number. That asymmetry, rather than any claim about the key being "more secure", is the honest argument for putting the operation on the request path. What is then done with those recorded operations — how they are retained, made tamper-evident and used as evidence — is a separate subject, as is what the worker does when the service cannot be reached at all.