How do you handle credentials and sessions for sites behind a login, like the bank and insurance portals you mention? Is the user's password or session cookie stored on your side, or does the generated MCP run against a session the user keeps locally?
Related: page content is untrusted input that now flows straight into an agent's context. Do the deterministic tools return only structured fields you've extracted, or can arbitrary page text (reviews, messages, product descriptions) pass through? That seems like the main prompt-injection surface for anything that can also perform actions like checkout.
For our hosted version, the session runs in our hosted browser. For the open source, it runs on a local browser.
In the hosted version, users can choose to pass logins at runtime or store them in our vault. Once a user logs in, we keep their session as a Chrome profile and attach it to a sticky IP, so that they stay logged in for longer.
Deterministic tools return only the structured fields, and don't parse the whole browser DOM. Since tools are deterministic, we also reduce the risk of prompt injections.
Hmm, I've also built a self healing system for agents to get data from various services. Do you have any sort of dashboard showing integration maintenance?
Great that you're building as well, we think it's a really interesting space.
We don't have a maintenance-specific dashboard. We do maintenance at execution time, so the dashboard paradigm doesn't apply as well. Instead of proactively checking for site changes, we check at execution time and repair integrations on-the-fly, when necessary.
Curious how this handles session isolation and rate-limiting when converting dynamic DOM heavy pages into MCPs.
If an agent hits a heavy SPA with infinite scroll or aggressive bot protection, does Pomerado handle edge-caching or proxy-level deduplication, or is it parsing raw DOM on every tool call?
Hi! Unlike traditional scrapers we don't parse the entire DOM on every tool call. Because we build custom integrations for every site, we can be more targeted in our approach, like only checking specific fields.
We don't edge-cache or deduplicate calls, to give users live data.
For session isolation, we give each worker its own browser, cookies, and IP to isolate user sessions and prevent rate limiting.
How do you handle credentials and sessions for sites behind a login, like the bank and insurance portals you mention? Is the user's password or session cookie stored on your side, or does the generated MCP run against a session the user keeps locally?
Related: page content is untrusted input that now flows straight into an agent's context. Do the deterministic tools return only structured fields you've extracted, or can arbitrary page text (reviews, messages, product descriptions) pass through? That seems like the main prompt-injection surface for anything that can also perform actions like checkout.
For our hosted version, the session runs in our hosted browser. For the open source, it runs on a local browser.
In the hosted version, users can choose to pass logins at runtime or store them in our vault. Once a user logs in, we keep their session as a Chrome profile and attach it to a sticky IP, so that they stay logged in for longer.
Deterministic tools return only the structured fields, and don't parse the whole browser DOM. Since tools are deterministic, we also reduce the risk of prompt injections.
What are the main advantages compared with https://github.com/mvanhorn/cli-printing-press
The obvious differences I can see are:
- generates an MCP server instead of a CLI
- at 'minting' time, uses OpenAI API keys, instead of coding agent subscription
- tries to solve for a particular use case, instead of all the site provides
Hmm, I've also built a self healing system for agents to get data from various services. Do you have any sort of dashboard showing integration maintenance?
Great that you're building as well, we think it's a really interesting space.
We don't have a maintenance-specific dashboard. We do maintenance at execution time, so the dashboard paradigm doesn't apply as well. Instead of proactively checking for site changes, we check at execution time and repair integrations on-the-fly, when necessary.
Curious how this handles session isolation and rate-limiting when converting dynamic DOM heavy pages into MCPs.
If an agent hits a heavy SPA with infinite scroll or aggressive bot protection, does Pomerado handle edge-caching or proxy-level deduplication, or is it parsing raw DOM on every tool call?
Hi! Unlike traditional scrapers we don't parse the entire DOM on every tool call. Because we build custom integrations for every site, we can be more targeted in our approach, like only checking specific fields.
We don't edge-cache or deduplicate calls, to give users live data.
For session isolation, we give each worker its own browser, cookies, and IP to isolate user sessions and prevent rate limiting.
A wall of text. Just post video with a link to that wall of text for someone who is on to read gened strings.