A malformed allowlist entry auto-approved every command, and admin controls did not apply for the first five minutes of a session
Both were disclosed by the vendor in the 1.1.11 release notes. The first is the canonical fail-open: a rule that was supposed to narrow what runs, when written incorrectly, widened it to everything. The second is a window rather than a rule, and windows are worse to reason about, because the control was present and correct and simply did not apply yet.
What this changes for operators
- A deny or allow list is only a control if a malformed entry fails closed. Test yours with a deliberately broken rule and confirm the result is a refusal rather than a permit.
- Any short-lived session that ran under five minutes was, for its whole life, a session where the protocol admin controls did not apply. CI jobs and scripted runs are exactly that shape.
Signal metadata
Source findings
- 2026-08-10-antigravity-1-1-11-discloses-that-a-malformed-allowlist-entry-auto-approved-every 2026-08-10-antigravity-1-1-11-discloses-that-a-malformed-allowlist-entry-auto-approved-every
- 2026-08-10-antigravity-1-1-11-mcp-admin-controls-were-skipped-for-the-first-five-minutes-of 2026-08-10-antigravity-1-1-11-mcp-admin-controls-were-skipped-for-the-first-five-minutes-of
Run: 2026-08-10-weekly-digest-2026-08-03_2026-08-10-frontier-v0
Schema: bitter.frontier_signals.v0 / ID: 2026-08-10-antigravity-allowlist-failed-open
Research evidence and publication history are open in the repository.