AI Coding Agents
Security
Authorization tests for coding agent changes
September 27, 2026 - 2 minute read
Authorization testing proves that each actor can perform only the actions allowed by policy. Coding agent changes can weaken that boundary while leaving normal user flows intact. A new route may check authentication but omit object ownership, or a refactor may enforce permissions in the interface while exposing the same action through an API.
OWASP's Authorization Cheat Sheet recommends deny by default, least privilege, validation on every request, and unit and integration tests for authorization logic. Those principles turn a broad security concern into observable acceptance criteria.
Build authorization testing from policy
Start with the application's existing roles, attributes, resources, and actions. Use the real policy source rather than reconstructing permissions from interface visibility. If policy is distributed across middleware, handlers, database filters, and an external engine, identify the final enforcement point for each path.
Choose cases from meaningful differences. Test two users with the same role but different resource ownership. Test a privileged action against an ordinary user. Test tenant boundaries, disabled accounts, expired grants, and resources whose parent has moved. Include anonymous requests where the route is reachable without a session.
Keep fixtures explicit. A fixture named admin says less than one that lists the grants used by the case. Stable policy data lets reviewers see whether a passing test proves the intended rule or merely inherits a broad permission.
Cover denied paths in authorization testing
Every allowed case needs a corresponding denied case close to the boundary. Assert the response and the absence of side effects. A rejected update must leave the record unchanged, avoid emitting an event, and avoid revealing protected fields through an error.
Exercise alternate entry points. Browser controls, REST handlers, GraphQL resolvers, background jobs, and bulk endpoints may reach the same operation. Hiding a button is useful interface behavior, but server-side enforcement remains the security boundary.
Object-level authorization deserves direct tests with valid identifiers owned by another actor. Random missing identifiers only prove not-found behavior. Also check collection queries and exports, where one missing filter can disclose many records without triggering a single-object guard.
Cached decisions need invalidation tests. Revoke a grant, change a resource's tenant, and confirm that later requests use the new policy. The test should control cache state directly instead of waiting for a production-style expiration interval.
Review authorization changes independently
The pull request should connect each changed permission to a policy requirement and list allowed and denied evidence. Review migrations or defaults that grant access to existing records. Avoid snapshots that hide the exact fields and status codes under review.
Factory's security review workflow uses repository threat-model context and reports findings at affected locations. Factory's Automated QA can drive separate user flows against a running application. These checks complement policy-level tests rather than replacing them.
Stop when the source of authorization policy is unclear or representative identities cannot be created safely. Never test with production credentials or broaden a service account merely to make the suite pass.
