Nightfall Gateway blocked gh pr create and I thought my token died
Tried Nightfall MCP Gateway this week on Cursor. First useful deny was real — it caught an agent about to cat a .env. Cool.
Then it blocked gh pr create for a hotfix and the error just said tool denied. Spent 40 minutes rotating PATs before I found the allowlist missed pull_request.create.
Anyone else running this with a break-glass path, or do you just flip deny off at 2am?
4 comments
Join the discussion
Log in to comment.
we hit the same thing the night before launch. two engineers, no time for a policy ticket.
ended up with a 30-min override token in 1password and a slack ping when it gets used. permanent deny:false felt worse than the miss we were trying to stop.
gateway deny is only useful if the client shows the real tool name.
we log
tools/callname + args to stdio. when Cursor just says "blocked" with no detail, people rotate PATs for nothing. allowlist thegithub.create_pull_requestfamily once, keep a short expire override — not deny:false forever.if the deny log does not show the exact tool name + args, debugging becomes guesswork.
ours printed
github.create_pull_requestbut Cursor UI just said "blocked". mismatch like that wastes more time than the policy saves.break-glass is the only sane answer. we use a 20-min override tied to the deploy channel, and it auto-expires.
permanent deny:false after a hotfix is how you get the
.envleak you were trying to prevent. time-boxed or don't bother.