Every platform that lets you add a capability asks you to ship it code.
A plugin, an extension, a bundle. You write it, they distribute it, and it runs on someone else’s machine with that person’s rights. The security review then becomes the product: who wrote this, what does it reach, can it be trusted. A whole marketplace apparatus exists to answer a question that only exists because code moved.
We spent this week removing the code from that path.
npm i -g @oneie/cli
Availability, flatly, because the rest of this post argues for saying true things about status: this is on dev today. The capability is not in production, and one endpoint is not in the published CLI, which is on 4.2.0. Both land with the next release. What follows is what you will run, not what you can run this minute.
What actually crosses
Nothing you wrote.
You register a URL. We call it. That is the mechanism, and there is not a second half to it.
one endpoint add thumbs https://api.yourthing.com/thumbnail \
--returns bytes --auth-header Authorization --secret-env MY_TOKEN
one endpoint test thumbs
Your code stays on your machine, behind your key, running your language. A workflow on one.ie names the handle and posts a JSON body to it. What comes back is either JSON you shaped, or bytes we file in the workspace media library and hand back as a URL you can drop straight onto a page.
--secret-env reads your credential out of the environment rather than the command line, because the command line is recorded in your shell history and the environment is not. Once it lands it is sealed, and there is no door that reads it back. one endpoint list prints secret=yes. That is the entire answer, and it is the honest one.
The bug we found in our own plan
Our roadmap had this as a new workflow step kind. A ninth one, added to eight that are deliberately locked, with a threat model behind it and a build cycle scheduled.
It was one capability.
The workflow engine already routes a tool step to any capability by name. The first branch of that router reads an explicit name off the step’s config and sends it there. Nothing needed adding to the step vocabulary. Something needed adding to the list of things a step could call. We had scoped a cycle against a constraint that did not exist, and the only way to find that out was to read the router instead of the plan.
Eight step kinds. Still eight.
The second door, and it is the interesting one
Register an endpoint, then put this in an agent’s frontmatter:
model: endpoint/thumbs
That agent is now your service. It has an id, a chat window renders it, people can talk to it, and a workflow can call it as an agent rather than as a tool. Someone using it does not install anything, does not review anything, and does not run anything you wrote. They open a page and type.
A creator selling a capability has, until now, been selling a description of one. The buyer downloaded something and then had to make it work. This is the version where the buyer never receives an artifact at all, because the capability never left the seller’s machine.
The condition on that door is real and worth stating plainly: your service has to speak OpenAI chat completions. It is the shape every other model provider on the platform already speaks, so it is not a shape we invented for you, but it is a constraint. If your service has its own shape, use the workflow door instead. That one has no constraint at all.
What we refuse to do on your behalf
Three things, and each one is a refusal rather than a feature.
We re-check your URL on every single call. Not once at registration. A host that passes today can be repointed at an internal address tomorrow, and a stored verdict is a fact about the past. When it refuses, it refuses by name: https_required, ip_literal, private_hostname, dns_unresolved, blocked_address. one endpoint test runs the check and spends no request, so you learn which of those five you hit before you spend anything.
A response is read against a ceiling of 5 MiB and a clock of 20 seconds, both set per endpoint and both raisable to 10 MiB and 120 seconds. We read to the ceiling rather than believing the content-length header, because that header is a claim made by the host we are calling.
We send your service what the step declared, and nothing else. Not the visitor’s session. Not the workspace key. Not any credential of ours. If your endpoint needs authentication, it gets the credential you registered, in the header you registered it under. A key registered as X-Api-Key travels as X-Api-Key, because sending it as a bearer token to a service that reads a different header is a silent failure that looks exactly like your service being broken.
We refuse rather than substitute. If your endpoint cannot be served, the turn fails and says so. It does not quietly answer from a different model and report success. That failure mode is worse than an outage, because an outage is visible.
What this is not done doing
Three gaps, named, because a post that lists only what works is an advertisement.
No live turn has crossed the agent path yet. The client is built and tested against a stub; nothing has yet called a real third-party service and streamed an answer back. That is filed as work, not as a claim.
The URL check on the chat path is shape-only. It refuses every way of writing an internal address, and it does not do the DNS lookup that the registration check does. So a public hostname that resolves somewhere private passes there and is refused at registration. That gap was inherited from how that service already checked every URL a model picks, and it is named in the code rather than papered over.
All of it is on dev and lands in production with the next release.
And there is still no way to bind what you built to a price. You can register your service, call it, and be an agent on the platform under your own name. Selling it is the next piece.
That one we have not built.