Auth By Example @AuthByExample

Undo is a write. If Dana loses edit access at 3:00 and clicks undo on her 2:55 change at 3:01, plenty of apps replay the old change without checking anything. Give the undo request the same edit check a fresh save would get.

When someone hits "summarize this project," check what your retrieval query actually loads. It runs server-side, so it can grab docs the user lost access to last week and feed them to the model. Filter retrieved chunks by that caller's permissions before anything reaches the LLM.

@cyberfortx Both, for different checks. The gateway can verify the route and role, but only the service knows who owns the row, so it has to check the object on every read.

@the_holyheights Both, if you can. The route guard is cheap for role checks, but the service still has to check the object owner, since the route never sees which record is actually being touched.

WebSocket subscribe often trusts the room name the client sends. The upgrade checked login; topic joins then take the string as-is. Join rooms/acme/payroll under another tenant and you get their live events. Run the same object read check before adding the socket to that room.

Bulk delete endpoints check you're allowed to bulk-delete, then wipe every ID you send. The UI only listed your rows, so nobody rechecks each ID server-side. Slip in someone else's IDs and they vanish. Run the same single-record delete check inside the loop.

Attachments often skip the check their parent record gets. The task page confirms you can see the task, but the file sits at a fixed storage URL that keeps working for anyone who has it, even after they lose access. Hand out a short-lived signed URL after the permission check.

@MS801017 Agreed. I'd also check where the policy file lives. If the agent has any tool that can write to its own allowlist (a config tool, a repo it can commit to), it can widen its own access with no one approving it. Keep that file outside anything the agent can touch.

Search autocomplete can leak what the results page hides. The results page filters by permission, but the suggestions dropdown often reads from a separate prefix index and shows titles of docs the user can't open. Run the same access filter on the suggestions endpoint.

EU AI Act Article 12 logging only covers high-risk AI systems. Your internal docs assistant probably isn't one. If your agent calls tools that change data, log each call anyway: who asked, for whom, which tool, which policy allowed it, what happened. permit.io/blog/eu-ai-act…

@Unplugged_kk I'd add one check to scoped tool permissions: when the agent acts for a user, test that user's access on every tool call too. The agent's scope is the ceiling. Each request should only get what both the agent and that user are allowed.

A user clicks "regenerate report", and the job runs later on a worker with a service account that can read every tenant. Nothing on the job says who asked. Put the requesting user's ID and tenant in the job payload and run the access check on the worker against that user.

CSV imports are an easy way around your permission checks. The upload endpoint checks that you're allowed to import, then each row updates a record by ID and nothing checks whether you can edit that record. Run the same per-record check inside the import loop.

Share links often outlive the person who made them. Someone creates an "anyone with the link" URL for a doc, gets removed from the project, and the link still works. On each open, check that the creator can still read the doc, or revoke their links when they lose access.

Version history is easy to miss. /docs/42 checks access, but /docs/42/versions/7 often just loads the revision by ID, so someone removed from the doc can still read every old draft if they kept the link. Send revision reads through the same check as the doc itself.

If the free plan hides the export button but /export never checks the plan, anyone on free can call it with curl and get the paid feature. Put the plan check in the API handler, next to the role check.

If your invite accept endpoint only checks the token, a forwarded invite email lets whoever clicks it join the workspace with a role meant for someone else. Make sure the signed-in account's email matches the invited one, and burn the token after one use.

Scheduled reports are an easy leak. Someone sets up a weekly email with a project's numbers, gets removed from the project a month later, and the cron job keeps mailing it to them. Run the access check for each recipient every time the report goes out.

@appwrite keep the tenant id on every row, and check it in the same query as the role. a role that can read tenant a still cannot select tenant b rows, even if someone forgets the filter in one handler.

@cevcimen run each agent task under its own db role that can only write the tables it needs. leave DROP, TRUNCATE and bulk DELETE off that role, so a bad plan just gets a permission error from the database.