Login answers one part of the question
A signed-in account can request a welcome credit, invite teammates or reserve an item. The session gives the application a useful context for the request. It does not, by itself, establish that every action is permitted, that the account is being used manually, or that repeated use fits the product’s rules.
OWASP distinguishes authentication from authorisation: establishing an identity is separate from deciding which actions it may perform. Its guidance calls for permission checks on every request. Bot protection belongs alongside those checks. A favourable automation assessment should never grant access that the account’s ordinary permissions deny.
Describe the entitlement before the signal
Consider a fictional workspace product that includes one introductory credit per eligible account. Write down what makes an account eligible and when the credit is consumed. The application must enforce that entitlement even if the caller sends requests manually. Automation evidence can inform an additional response when repeated attempts create a separate problem.
Keep these records distinct: the account was authenticated; the credit had already been claimed; repeated attempts were observed; the request was refused under the credit rule. That explanation is more useful to support than a single label saying the account was a bot. It also helps the team correct the right part of the system.
Use account context your server can trust
When connecting a protection service, derive the account context from the application’s authenticated server session. A customer identifier submitted in a browser field is not enough to establish which account made the request. Decide how the integration represents that account and document which service is responsible for checking it.
Test account switching explicitly. Activity from account A must not become account B’s history just because the browser stays open. Check logout, session expiry and a second account using the same device. Guest traffic needs its own policy because it lacks the same account context; silently assigning it to a previous account creates a different problem.
Restrict the affected action first
If repeated credit claims are the concern, start by controlling credit claims. Decide whether the account can still sign in, read its existing work and contact support. A temporary restriction on a costly action and suspension of the entire account have different consequences. Make that choice deliberately, with a reason the team can explain.
Document how long the restriction lasts and what evidence can remove it. For example, support might correct an entitlement record after finding a failed initial transaction. The correction should change the relevant state and leave a reviewable record. Simply allowing the next request through while an old restriction remains active can produce confusing results.
Give approved tools a defined permission
Some customers use automation because the product is more useful that way. A business account might run a scheduled export or maintain a permitted integration. Define its actions, ownership and allowance. An account’s paid status alone should not create an unlimited exemption, just as the presence of automation should not erase an agreed permission.
Review exceptions when their scope changes. A tool authorised to read records may later request the ability to create them. Treat that as a new permission decision. Keep the application’s normal access controls in force and make the exception visible to the people who investigate unexpected activity.
Review the account’s outcome
After a protection change, inspect both the restricted action and the customer’s ability to recover. Did the unwanted credit claim stop? Could an eligible customer complete the intended workflow? Was a correction needed? A restriction count cannot answer all three, and an unresolved case should remain unresolved until someone checks it.
Blokk Bot’s account-protection approach centres on that connection between evidence, a specific policy and a controlled response. Account context can make a decision more precise, while its limits remain clear: one authenticated account is not a universal identity for every visitor, device or future attempt.