The “risk accepted” stamp is doing too much work
In August 2026, Patrick Gray sat down with Knocknoc CEO Adam Pointon for a Risky Business Soap Box on why Zero Trust-as-comprehensive-architecture keeps failing – the same week the rest of this news cycle was gym-class agents, Hugging Face, and water utilities. Their diagnosis is blunt. Most networks still look like they were designed in 1999. Most Zero Trust products look like they were designed for 2049. In the gap, organisations stamp “risk accepted” and move on, because ripping out the network to match the slide deck is not a project anyone can finish.
They pitch something in the middle: Zero Trust(ish) networks. Apply the principles selectively, against risky assets, instead of waiting for a re-architecture that will not arrive. That is not a watering-down of the idea. It is an admission that a principle with no enforcement point is documentation.
This post is a companion to that argument. If you cannot rebuild the network, you can still pick a surface where never-trust-always-verify is small enough to ship and high-leverage enough to matter. For most organisations deploying agents and integrations in 2026, that surface is outbound calls to APIs they do not own.
Why this seam and not another
Zero Trust, as NIST frames it, is a decision made per request: authenticate the caller, authorize the action, assume breach, log the outcome. The reason full-network Zero Trust is so heavy is that the “request” is every packet, every east-west hop, every legacy protocol, every printer. The reason outbound vendor APIs are a better first protect surface is that the request is already a discrete HTTP call, already crossing a trust boundary you do not control, already carrying a credential that is probably too wide.
You cannot microsegment a SaaS CRM out of the box. You cannot put an agent on a payments provider’s host. You cannot wait for every vendor in the stack to expose permissions fine-grained enough for a non-deterministic client. You can decide that no process in your environment – agent, script, integration, BI tool – talks to those APIs except through a control point that verifies each call.
That is the same selective logic Knocknoc is arguing for, applied to a different risky asset. Identity and device posture remain the right starting point for human access to your applications. The complementary gap is machine access to their applications. Agents have made that gap urgent: they generate more calls, with less predictability, against a larger set of third-party APIs, than the service accounts they replaced.
Never trust, always verify, on a call you can see
On the outbound seam, Zero Trust principles map onto objects you can actually configure.
Never trust the caller with the upstream secret. The agent authenticates to the proxy with its own credential. The vendor key stays in a target credential and is attached only after the call is allowed. A leaked agent config, a verbose log, or a dumped context window does not contain the Salesforce token, the GitHub PAT, or the payments secret.
Verify every action, not just every identity. A valid proxy credential is not a wildcard. proxyDefaultRuleEffect: "deny" means the call is unauthorized until a rule matches. The rule is the per-request authorization decision:
{
"effect": "allow",
"ruleActive": true,
"methods": ["GET"],
"path": {
"path": { "pattern": "^/crm/v3/objects/contacts/[^/]+$" },
"presence": "must_exist"
},
"notes": "Integration may read a single contact by ID"
}Identity answered who is calling. This rule answers whether this GET, to this path, is permitted. That is the Zero Trust move most NHI programmes never reach, because they stop at “the service account is in the inventory.”
Assume breach, cap the damage. A compromised proxy credential can do only what its proxy allows, at the rate its meter allows. Rotate the target credential without touching the caller. Revoke the proxy credential without rotating the vendor key. The blast radius has a number.
Log the decision. Every forwarded or refused call is a record. If you cannot answer “who called which vendor API, when, and whether policy allowed it,” you do not have Zero Trust on that surface. You have a VPN and a story.
What “selectively” honestly means
It means you do not need to put every internal RPC through the same gateway on day one. It means you start with the calls that leave your perimeter toward systems you cannot patch: CRM, payments, ticketing, cloud AI APIs, partner gateways, the booking system, the vendor telemetry feed. It means you accept that the rest of the 1999 network is still there, and you stop using that fact as a reason to leave the highest-leverage crossing ungoverned.
It also means this is not a Zero Trust product substitution. RequestRocket does not replace your identity provider, your ZTNA, or your device posture checks. Those remain the right tools for the surfaces they were built for. The outbound API layer is the surface they were not built for, which is why it is still sitting under a “risk accepted” stamp while agents are already in production.
Next steps
Take Knocknoc’s advice literally: pick one risky asset. Name the third-party APIs your agents and integrations already call. Put a deny-by-default proxy in front of the one whose compromise would hurt most, and move the vendor credential out of the caller’s environment. That is a Zero Trust increment you can ship without a network programme.
This is post 3 of APIs You Don’t Own. Least privilege is scoped at the call. The credential half of the same seam is tokens that do not expire themselves. RequestRocket is runtime access control for AI agents and apps calling APIs you don’t own – every call gets a least-privilege credential, a policy check, and an audit record, with no code changes. Read the documentation, or start for free.