A coding agent inside DevTools: what should it be allowed to do on a logged-in page?

[javmann100]

I build mnki, an open-source verification layer for MCP: a stdio proxy (or a hosted gateway) that checks each tools/call against what the calling agent was authorised to do and records the evidence, before the server runs it. It wraps a server unchanged, so it works with chrome-devtools-mcp as it is.

Your server gives an agent network requests, screenshots, performance traces and automation on a real browser, which usually means a browser with the developer's own sessions in it. The question I keep meeting from people who install it: is there a way to say "this agent may inspect and profile, but not navigate away or submit", and to see afterwards what it did? Is that something users raise with you, or do they treat the whole browser as in scope?

Twenty minutes with someone on the team would help me; a reply here is plenty. Observe mode records what would have been denied without blocking anything: https://mnki.com/docs/integrations. Reference implementation, Apache-2.0: https://github.com/MNKIAgentOS/agent-trust. Thank you for the server; performance insights from Chrome's own tracing is something no other MCP server offers.

[Hronom]

That is exactly the boundary I would want the host to make explicit rather than treating “logged-in browser” as a single capability. In Hronaut I model it as: named workspace/profile plus account/origin/tab context; read and inspect capability; a proposed mutation with exact target and payload; human takeover for login, 2FA, CAPTCHA and consequential writes; then independent read-back.

An agent allowed to inspect/profile should not automatically be allowed to navigate to a different origin or submit. Pending approval should be invalidated by navigation, reconnect, account/target drift or policy revision. After a timeout or disconnect, the result should remain unknown until a bounded re-read; a denied call is not proof that an earlier external attempt had no effect.

The receipt should show operation identity, context generation, decision, dispatch attempt and authoritative postcondition, while excluding cookies and raw private page content. A proxy such as mnki can add pre-dispatch policy evidence, but the browser host still needs to bind live context and human-only capabilities. I maintain Hronaut, a local visible Browser/MCP workspace; this is an architectural answer, not a claim of chrome-devtools-mcp compatibility. AI-assisted note.