Performance

Section 16 · From docs/MCP_PRIVACY.md on GitHub

Measured on an AMD Ryzen 7 5800H with Python 3.13.13, on a machine that was running other jobs at the same time (load average around 5). Each bulk figure comes from a fresh process with the garbage collector paused during the run. Even so, the same run varied by a factor of two to three between attempts, so the tables give the fastest observation and, where the spread was large, the range.

16.1 Bulk throughput

A synthetic 50,000-asset EC2 dataset (100 accounts, three regions, private IPs and EC2 DNS names on every asset, public IPs on one in seven, a user_data password on one in fifty, tags with an owner e-mail) dumped as one 34.6 MB JSON value and passed through each profile's pipeline. A tool never returns 50,000 assets in one result; this measures the per-string cost at scale.

Run	Total	sanitize	redact	project	Vault entries
standard	7.1 s	3.2 s	2.2 s	1.7 s	0
standard, sanitize.detect: false	5.1 s	1.0 s	2.3 s	1.8 s	0
strict, cold vault	34.6 s (up to 51 s)	3.2 s	29.4 s (up to 45 s)	2.0 s	407,544
strict, warm vault	14.1 s (up to 22 s)	3.2 s	9.0 s	2.0 s	407,544
strict, warm, redact.cache_size: 2000000	9.2 s	3.4 s	3.8 s	2.0 s	407,544

standard is the same cold and warm because it issues no pseudonyms. Most of the cold strict cost is issuing 407,544 pseudonyms: every asset's UUID, name, ARN and its components, IPs, DNS names, owner e-mails and tag values. Peak RSS, payload included, was about 363 MB for standard, 573 MB for strict and 584 MB with the larger cache. annotate took under 0.2 s in every run.

Vault persistence, for a vault of 200,100 entries (100,000 ARNs with their components): issuing them took 1.0 s, an encrypted save 2.2 s for a 39.9 MB file, loading it 2.6 s, and a plaintext save 0.32 s.

16.2 Per call

Through CloudGMCPLayer.call_tool on a 50,000-asset dataset, median and 95th percentile in milliseconds. "First" means the pseudonyms were new; "repeat" is the same calls again.

Call	open	standard	strict
get_asset, first	0.53 / 0.69	0.96 / 1.30	1.49 / 1.94
get_asset, repeat	0.52 / 0.66	0.80 / 1.07	0.89 / 1.03
find_assets text query, 50 results	38.0 / 43.5	43.3 / 47.9	51.7 / 61.5
find_assets by account, 500 results, first	9.4 / 11.6	58.1 / 62.8	131.5 / 184.8
find_assets by account, 500 results, repeat	9.0 / 9.9	30.6 / 32.2	41.5 / 106.0

For a single asset the policy adds about half a millisecond under standard and one millisecond under strict the first time. For a full page of 500 it adds 20 to 120 ms. A text search is dominated by the search itself.

16.3 Tuning

• Keep results small. Pagination, the tools' own fields arguments and include projections cut the work for every later transform. Cost grows with the number of strings, not their length.
• Raise redact.cache_size above the number of distinct strings your results carry if you pseudonymise large results repeatedly. The default of 200,000 is cleared when full, so on the 50,000-asset run it keeps emptying itself; at two million the warm redact stage dropped from 9.0 s to 3.8 s. Each entry costs memory (about 11 MB more peak RSS in the run above).
• Disable detectors you do not need (disabled_detectors), and give custom detectors hints. A detector without hints runs its regex on every string.
• Do not pseudonymise what you will keep anyway. Every entity whose strategy resolves to keep costs nothing, so a policy that pseudonymises only accounts and ARNs is much closer to standard than to strict.
• sanitize is a third to a half of the standard cost, mostly the injection regex. Turning detect off saves it and loses injection detection; raising min_length is a gentler cut. Leave it on for anything facing an external model.
• Avoid autosave on large vaults. Each save rewrites the whole file; at 200,000 entries that is 2.2 s on every call that issues a new pseudonym. Save on a timer or at shutdown instead.
• A stable vault key costs nothing and avoids re-issuing pseudonyms after a restart.
• strict limits every caller to 240 calls a minute. Raise it in your own policy if an agent legitimately needs more, rather than switching profiles.