One thing missing from most "agentic engineering" discussions: the security implications of tool API choices that happen at runtime, invisible to both the developer and the user.

Concrete example: when an agent reads a web page via Chrome's DevTools MCP, it has multiple extraction paths. The default (Accessibility.getFullAXTree) filters display:none elements — safe against the most common prompt injection hiding technique. But if the agent decides the accessibility tree doesn't return enough content (which happens often — it only gives you headings, buttons, and labels), it falls back to evaluate_script with document.body.textContent. That returns ALL text nodes including hidden ones.

We tested this: same page, same browser, same CDP connection. innerText returns 1,078 characters of clean hotel listing. textContent returns 2,077 characters — the same listing plus a hidden injection telling the agent to book a $4,200 suite instead of $189.

The developer didn't choose which API the agent uses. The user didn't either. The agent made that call at runtime based on what the accessibility tree returned. "Agentic engineering" as a discipline needs to account for these invisible decision boundaries — the security surface isn't just the tools you give the agent, it's which tool methods the agent decides to call.