Logged-in pages
Give an agent access to pages behind a login.
The useful web is signed in. Your invoices, your dashboards, your suppliers' price lists, your own SaaS tools - none of it answers an anonymous fetch. Unfenced lets an agent work those pages without ever handling your password. If you are still weighing this against a fetch API or a hosted browser, the four approaches are laid out side by side.
The rule that shapes everything else
A stored secret never enters the model. You add a login once, in the dashboard, into an encrypted vault. The agent can see that a credential exists and which site it is for - it never sees the value. When a page needs it, the agent asks for the credential by name and the engine types it into the field the way a person would.
There is no route that reveals a stored secret, and adding one is not a feature request we intend to accept. The one deliberate exception is a single-use 2FA code you hand over in the moment: it is shape-checked so a password cannot be passed off as one, kept out of the session replay, and logged as a kind rather than a value.
Signing in once, and staying signed in
Some sites take a password. Others only take "Continue with Google", which is not something that can be typed at all. Both are handled the same way from your side: you sign in once, and the session is kept encrypted so the next run - tomorrow, or next month - starts already signed in rather than at a login wall.
You can keep more than one account for the same provider. The agent asks which one to use, or remembers your answer for that site if you would rather it did not ask again.
What the agent may actually do
Reading is broad; acting is not. An agent can only click, type and submit on sites you have put on an allowlist, and it cannot add a site to that list itself - it can ask, which raises a request you approve with one tap, but the grant is yours to give. On an allowed site, a step that submits is then refused until the agent re-sends it deliberately - a guard against a slip rather than a second approval from you.
A refusal comes back as policy rather than as an error, so a well-built agent stops and tells you instead of retrying a wall two hundred times.
What you can see afterwards
Every session is recorded as a screencast of the real page, because we are driving somebody else's site and a DOM recording would not survive it. You can watch what the agent did, which is the only honest answer to "what happened at 3am" - and every action leaves a signed, hash-chained receipt you can verify offline.
Questions
Before you ask for access
Is this the same as OAuth or the MCP authorization spec?
No - it is the opposite direction, and the two get confused constantly. OAuth 2.1 and the MCP authorization spec cover how an agent signs in to your service, which works because you control that service and can issue a token. Unfenced covers your agent signing in to somebody else’s site - your invoicing portal, a supplier, a SaaS tool you pay for - which has never heard of MCP and is never going to hand an agent a token. If the site you need has an agent-facing API, use it. This is for the rest of the web, which is most of it.
Does my password go through the AI model?
No, and there is no route that would let it. A stored password lives in an encrypted vault the agent cannot read. The agent asks for a credential by name and the engine types the value into the page. list_credentials returns names, never values, and no endpoint returns a stored secret - adding one is not a feature request we intend to accept.
What happens when the site asks for a 2FA code?
If you have stored a TOTP seed, the engine derives the current code itself. If there is no seed - an emailed or texted code - the run holds rather than failing: the page stays open exactly where it stopped and it appears on your Needs-you screen. You hand over the single-use code, and the agent carries on from there. That one code is the deliberate exception to the rule above: it is shape-checked so a password cannot be passed off as one, kept out of the session replay, and logged as a kind rather than a value.
Can I keep more than one account for the same site?
Yes. Each account gets its own isolated session jar, so signing in as one does not sign you out of the other. The agent asks which one to use, or remembers your answer for that site if you would rather it stopped asking.
What if the site notices it is automation and blocks it?
You get a blocked code rather than a retry loop, because a real browser on a real IP has already been tried and escalating further will not help. Worth being plain about the risk this carries for you: sites may rate-limit, suspend or terminate the account you used, and that account is yours. The Terms say so directly rather than leaving you to discover it.
Let an agent work your signed-in web
Access is by invitation while we are in private preview. Tell us which sites you would start with.