A request tracker stores employee names, team assignments, and approval decisions. Start the security discussion with those records and the people allowed to use them.
An internal tool can still hold sensitive information or make consequential changes. Its audience size alone does not tell you which controls it needs.
Define the access rules in examples
For each role, describe a permitted read, a permitted change, and a request that must be refused. Include record ownership and team or tenant boundaries where relevant.
Then test the rules through the backend operation. Hiding a button can improve the interface, but it does not establish that an unauthorized request will be refused. Keep authentication, authorization, and interface behavior distinct during review.
Use separate identities for the tests. Confirm that a role change or revocation has the expected effect. Record any caching or session behavior that affects when the change takes effect.
Write a small access matrix
For the equipment tracker, the following is an example policy to discuss with the business owner. It must be implemented and tested before being treated as a control.
| Action | Requester | Assigned team manager | Unrelated team member |
|---|---|---|---|
| Read the request | Own request | Team request | Refused |
| Edit the request details | Own pending request | Only if policy explicitly permits | Refused |
| Approve or decline | Refused | Permitted, except own request | Refused |
| View decision history | Own request | Team request | Refused |
Ask what happens when an employee changes teams, a manager leaves, or a request is reassigned. The answer determines whether access follows the current team, a historical relationship, or another rule. Make that choice explicit.
Test a direct request for a record the user should not see. The expected result should omit its contents, not merely hide the screen that links to it. Repeat a relevant check after access is revoked. If the old session retains access, investigate and document the mechanism before accepting the boundary.
Use the same policy when reviewing exports and background jobs. A correctly restricted screen can still be undermined by an export or scheduled task that uses broader access without an appropriate reason.
Follow sensitive information through the workflow
Identify where information is collected, stored, sent, logged, exported, and deleted. If a model provider receives content, document what is sent and the settings or terms that govern it. Keep credentials out of browser code and prompts.
Use synthetic records for development and demonstrations. Give support staff enough diagnostic information to investigate failures without unnecessarily copying sensitive content into logs or screenshots.
Define the retention and recovery requirements with the people responsible for the data. Then verify the actual mechanisms selected for the application. A written requirement is not evidence that a backup or deletion process works.
Make the review observable
OWASP ASVS provides a structured reference for application-security verification. Use the relevant requirements to organize review with a qualified person; mentioning the standard does not certify an application.
For generated code, review the same controls you would review in any implementation. Check inputs, permissions, secrets, dependencies, and failure behavior. Ask the agent to report what it exercised and what it inferred.
On OBTO, verify safeguards against the current implementation and the target application's behavior. If a content hash is checked only when supplied, describe that condition. Do not turn an optional check into a claim of unconditional enforcement.
The OBTO security page is a starting point for product questions. Keep the application's own access matrix and test evidence with its release record, including unresolved findings and their owner.