A short piece of fiction, written by API Evangelist. The reader is imagined; the post, and every number and quotation from it, is real: "Find The PII And Secrets An API Exposes Before You Hand It To An Agent," Kin Lane, November 4, 2026, https://apievangelist.com/2026/11/04/find-the-pii-and-secrets-an-api-exposes-before-you-hand-it-to-an-agent/
Marisol was a platform engineer at a freight company, and her team's agent demo had worked on Tuesday. By Wednesday afternoon she was reading a blog post because her manager had asked what the thing would actually see. She didn't have an answer yet.
The post began with that same question. Which names, email addresses, phone numbers, passwords and keys pass through the operations you just gave an agent? Kin Lane said most teams answer by reading the OpenAPI by hand, if they answer at all. She winced, because that was her plan for Friday.
She read about the tool, classify_api_fields, and its REST twin. The example was the Swagger Petstore, and her first reaction was a small eye-roll. Of course it was the Petstore. Nobody ships the Petstore. But the numbers were hard to argue with. There were nineteen operations, and the tool flagged six of them as carrying sensitive data, with 24 PII fields and 8 secret fields. The pet side was clean apart from one header, and everything personal lived in the User schema. Her own contracts had a User schema too, and so did every contract she'd ever worked on.
What caught her was the password. The post said GET /user/{username} returns one in its response, and called it the field you'd least want flowing into an agent's context window and then into a log. She thought about the log line. Nobody on her team had asked where an agent's context ends up afterward.
She was less comfortable with the next part, and she kept rereading it. The tool had not flagged username, even though it appears in the URL of three operations. The post said so plainly: "Treat the output as a floor, not a ceiling." She appreciated the honesty, but it unsettled her. A tool that misses identifiers that aren't named like personal data is a tool that lets people feel finished. She could already picture a steering meeting where someone says the scan came back clean. She decided she would say, out loud, that clean only means clean by field name.
She also noticed the post didn't pretend to settle the query-string question. The classifier labels the password a secret, but it doesn't tell you a query string is the wrong place for it. That judgement stays with you, and she found she preferred that to a tool claiming more.
The CI idea was tempting. Run it on every pull request and "fail the build when piiFields or secretFields goes up". Part of her wanted that wired in by Friday. Another part knew her team would meet a failing build with a waiver request, and that she would be the one answering those requests. She left it for later.
The post said it was free, and that settled what to do. She didn't need a policy or a meeting. She opened the OpenAPI file for the shipment-tracking service, the one the agent already had tools for, and copied it into a scratch note. Then she opened the MCP server's governance endpoint and called classify_api_fields with the document.
While it ran, she typed a line at the top of her notes. It said to ask the privacy lead whether a customer reference number counts as personal data, since the scanner wouldn't tell her.