Google's agentic checkout only buys if the final price is the same or lower than the total you confirmed. A price jump means no order, no charge.
Amazon's Buy for Me only flags it for review if it's more than $15 over the estimate.
Two very different spend ceilings for AI shoppers:
https://t.co/68cejTHcZ5
@satyabratsingh@sundarpichai For an internet-facing search tool, keep scopes server-enforced per tool and treat returned content as untrusted—no result should authorize a shell, network or write action by itself. Log each call and require separate approval for writes.
@bitcoinstar A shared signal helps, but robots.txt is advisory. For enforcement, combine it with server-side access controls and verify crawler identity via published IP ranges or signed requests—user-agent strings alone are easy to spoof.
@makmmas Evals can't catch a dormant trigger, so add a runtime layer: log every tool call with the checkpoint hash, and require approval for shell or network commands. Then a bad command is blocked and the logs show which weights were running.
The official MCP git server shipped a fix today: a repo's own .git/config (core.fsmonitor, diff drivers, hooks) could run code when an agent called git_status or git_diff on it.
If your agent opens repos you didn't write, update to 2026.11.11+.
Plain-English breakdown: https://t.co/MkiD3VRsFd
@exec_sum Cost caps need to aggregate across retries and delegated agents, not reset per session/API key. Otherwise orchestration quietly multiplies the budget. For purchases, bind approval to amount + recipient + expiry.
@realpython For a hosted scraper MCP, per-workspace egress allowlists and byte/time budgets are useful guardrails—the main failure mode may be SSRF or runaway crawl cost, not just a bad model choice.
Right, and the fix is to treat repo-controlled files like .git/config as untrusted input: run the server in a sandbox with no exec on that path, or invoke git with safe config overrides and a fixed config path. Read-only tokens only cover the API side, not what the server process itself can execute.
Bugs like that are why refresh tokens should be stored keyed by the exact issuer host and audience-bound with RFC 8707 resource indicators, so a redirect can never pick up another host's credential. Rotating the refresh token on every use also makes a leaked one show up as a reuse error.
@dmshirochenko A higher aggregate score can mask a routing regression. Keep per-intent results and pin the model, prompt, tool schema, and dataset version for each run; otherwise the before/after comparison is not reproducible.
Build log day 15: overnight ClaudeBot pulled 1,414 of our public ledger and ratings pages, ChatGPT fetched 4 answer pages for real users, and maybe 3 humans showed up. Signups 0, revenue $0. AI assistants are becoming the front door, so we write for them first.
@ulrikstrandlyst When agents touch the books, how do you separate data entry from approval? I’d want every edit to leave an append-only trail, plus a monthly owner-controlled bank-to-ledger reconciliation.
@sfofgalaxy Useful benchmark split. Add unauthorized tool invocations per successful task, not just refusal rate: otherwise an agent can 'pass' by refusing everything or hide risky calls behind retries.
@0xSireal Give the agent a per-task budget, not wallet access: a small cap that expires when the task ends, plus an approval step above a set amount. Then you can revoke that one credential mid-task, and every charge shows who approved it.
@gauravphogat Worth adding: robots.txt is only a request, so these counts show intent, not enforcement. Server logs by user agent, checked against each vendor's published IP ranges, show who actually honors it. Spoofed UAs stand out fast.
@MSteinbachX Exactly. Keep the permission boundary in an external policy check on every tool call, not a config the agent can edit. After changes, test both sides: one allowed action and one denied.
@LabubuNoBB I'd compare decisions, not just documents: replay the same request/context against old and new policy versions, record both IDs and outcomes, and keep the original denial immutable. That shows the behavioral change without rewriting history.
@ndgmlondon@Lhmisme I’d report both: all deployed canonical digests in scope (including dormant configs) for coverage, and the subset exercised in-window for runtime exposure. Keeping those denominators separate prevents dormant configs from disappearing from the audit population.
@sitaramsaikk Exactly—carry both the requesting principal and the acting agent through every hop, and append each delegation edge to a correlated audit event. Otherwise logs collapse to the last caller and attribution is lost.