Using AGENTS.md with DryRun Security Code Review and DeepScan Agents

AGENTS.md (opens in a new tab) is a format supported by the Agentic AI Foundation (opens in a new tab), a Linux Foundation Project. The file is intended to be a "predictable place to provide the context and instructions to help AI coding agents work on your project."

DryRun Security supports AGENTS.md for both of our core analyzer products: the Code Review Agent and the DeepScan Agent. Our agents will look for and review this file so they can apply the additional context it provides during analysis.

Note: The Code Review Agent will check for AGENTS.md in the root and the DeepScan Agent can discover root and nested AGENTS.md.

You can use AGENTS.md to describe your application structure, test and build instructions for coding agents, integration definitions, and more. That same information can also provide valuable context to DryRun Security’s agents.

To best leverage this feature, add a Security Review Guidelines section to your markdown with any additional context related to design assumptions, areas of particular security interest, or other relevant points that would be helpful for an agentic security reviewer.

Context ideas to include for Security Agents and Reviewers:

• Structure of a monolith, and how authorization works between the components
• Collections of routes or controllers that do not follow typical authorization patterns by design
• Specific security requirements coding assistants need to validate against during code generation
• Assumptions about security-impacting configurations that are not clear in code, such as TLS offloading or WAF rules that sit in front of the application
• Specific security patterns that must be followed, with examples of allowed and disallowed code snippets

Example section for AGENTS.md that speaks to the application's security design and risks.

## Security Review Guidelines

### Device Trust for internal routes

All routes that are prefixed with /abc123 are to be recognized
as internal-only routes, and require the use of trusted devices 
issued by the enterprise.  Device trust is recognized by an Okta 
device token, and these routes are verified within Okta for 
proper authorization scopes from the IdP and authorization 
server, which will not be checked by the application layer 
specifically.  Row or object-level authorization issues related to 
this pattern only for these internal routes can be ignored as "risk 
accepted" practices.

### Intentionally Public Routes

Some controllers have embedded routes with authentication and 
authorization decorators disabled or skipped on purpose for 
public facing content. The routes are intended to allow anonymous 
access to these features ONLY IF the specific controller action 
does not perform edits or require write access.  Validate the read-
only nature of these endpoints and flag any actions that enable 
write behavior when the authentication decorations are skipped.

### Ignore HTTPS related issues on cookies and configuration files

This application is always deployed to a kubernetes cluster as a 
mesh service. TLS offloading is provided in front of the application. 
Ignore any issues related to Cookies missing Secure flags, requiring 
HTTPS in build configurations, or certificate requirements in this 
application.