Full-web access for AI agents
Your agent is smart enough.
The web just won’t let it in.
Datacentre IP. No browser fingerprint. A login it must never be handed the password for. Unfenced is the way through - any URL, through a real browser on a real IP, returned as clean markdown, plus the pages behind a sign-in, a click, or a form.
- read and act over MCP
- 3 fetch tiers
- 4 output formats
- real residential IP
- signed hash-chained receipts
What changes tomorrow morning
Four things your agent still cannot do.
Not capabilities in the abstract - the specific walls an agent hits an hour into any real task.
Read the pages that refuse everything else
The ones that answer a person and stonewall a script: built in JavaScript, bot-walled, or serving a challenge page.
Work inside your accounts, not around them
Your invoices, your dashboards, your suppliers’ price lists. Sign in once and the session is still there next month, so a run on a schedule is not a run that starts at a login wall.
Stop at the wall instead of guessing
A password field, a CAPTCHA, a consent box. The run holds, the page waits exactly where it stopped, and it is on your Needs-you screen with the reason - so you clear it and the agent carries on from there.
Show you exactly what it did at 3am
Every session recorded as a screencast of the real page, and every action a signed, hash-chained receipt you can verify offline. Not a log it wrote about itself.
The bottleneck is not intelligence. It is authority.The thesis Unfenced is built on
How a fetch works
Starts cheap. Climbs only as far as the page forces it.
Most of the web does not need a browser, and paying for one every time is slow. Every reply names the tier that answered and whether it escalated, so a slow fetch is explainable rather than mysterious.
A quieter kind of workspace
Good spaces make room for focused work.
What matters
- Natural light
- Room to think
# A quieter kind of workspace
Good spaces make room
for focused work.
## What matters
- Natural light
- Room to thinkBoth Chrome modes can click and scroll. The cursor illustrates those commands.
Start with a simple request.
Renders JavaScript without a visible browser window.
A full browser window when headless Chrome is refused.
What stays yours
It uses your logins. It never learns them.
An agent that can do anything is not a feature, it is a liability. The secret has no path back to the model - not by policy, by plumbing.
No route reveals a secret
There is no endpoint that returns a stored value, and adding one is not a feature request we intend to accept.
It cannot grant itself a site
Acting is gated by an allowlist only you can add to. The agent can ask - which raises a request you approve with one tap - but the grant is yours to give.
Nothing submits on a stray click
Click, type, submit, paginate, download - and a step that submits is refused until the agent re-sends it deliberately, even on a site you have already allowed. A guard against a slip, not a second approval from you: the approval you give is the site grant beside it.
Failures that are instructions
needs-credential, blocked, transient,
http-error. An agent that retries a refusal two hundred times is one
that was told only the status code.
One call
A URL in. Agent-ready text out.
The plain HTTP API underneath everything else. The same call is one tool over MCP and one method in the SDK - over MCP an agent gets the rest of the verbs too.
# Ask for a page. curl -s -X POST https://unfenced.ai/api/jobs \ -H "Authorization: Bearer YOUR_KEY" \ -H "content-type: application/json" \ -d '{"url":"https://example.com","format":"markdown"}' # {"jobId":"..."} # Read it back - clean markdown, not raw HTML. curl -s https://unfenced.ai/api/jobs/JOB_ID \ -H "Authorization: Bearer YOUR_KEY" # {"status":"done","result":{"doc":{"markdown":"# Example Domain\n\n..."}}}
-
MCP
One remote connector, read and act.
unfenced.ai/api/mcp -
HTTP
A plain REST API, any language.
unfenced.ai/api -
SDK
A zero-dependency TypeScript client.
not on npm yet
Questions
Before you ask for access
What makes this different from fetching the URL myself?
Two things. Most of the web that matters refuses a plain HTTP client - a datacentre IP, a missing browser fingerprint, or a challenge page - and Unfenced climbs to a real browser on a real IP when a page demands one. And what comes back is clean markdown rather than raw HTML, so a model reads content instead of spending its context on navigation and script tags.
Can it reach pages behind a login?
Yes, and that is the part most tools stop short of. A person stores a login once in an encrypted vault; the agent fills it by name and the value never passes through the model. There is no route that reveals a stored secret. See logged-in pages.
What stops an agent doing something I did not want?
An allowlist you control. An agent can read widely, but it can only click, type and submit on sites you have allowed - and it cannot grant itself a site: it can ask, which raises a request you approve with one tap. A step that submits is then refused until the agent re-sends it deliberately, so nothing commits on a stray click. Refusals come back as policy, not as errors worth retrying.
How do I connect it?
One remote MCP connector, a TypeScript SDK, or the plain HTTP API - all authenticated with an API key. Over MCP an agent gets a tool per verb: read a page, drive a live one, hold a login. A failed call returns a structured code that tells the agent what to do next, not just an HTTP status.
Why is access by invitation?
Because every account gets a real browser on real infrastructure, and we would rather run a small preview properly than a large one badly. Ask for access and tell us what you would point it at - that is genuinely what we sort the queue by.
Private preview
Tell us what you would point it at.
We are letting people in a few at a time, and what you write is genuinely what we sort the queue by. One specific sentence beats a paragraph.