Skip to content

Security Review

Small change. New way in.

Find the security risks a diff can introduce, from application access
to AI tool use. Get the code, the consequence, and a direction to fix it.

Start free Follow a finding

Where does trust cross the line?

Illustrative code & findings
Authenticated requestTenant A
Missing tenant check Lookup by invoice ID alone
Protected resourceTenant B's invoice
api/invoices.pyLines 18-22
def get_invoice(invoice_id, actor):
return db.invoices.find_one({
"id": invoice_id
})
The actor is known. Its tenant is never checked.
CloudAEyeBroken access controlHigh

A valid login.
The wrong person's data.

The query accepts an invoice ID but ignores the actor's tenant. Knowing another tenant's ID is enough to retrieve its record.

Bind the lookup to the authenticated tenant. Test both allowed and cross-tenant requests.

Application security / Review from your coding agent or pull request.

Different code.
The same trust questions.

Security review wherever a change introduces input, authority, or access. From application endpoints to AI-connected tools.

Find web application weaknesses.

Application security / For backend and AppSec teams

Review changes for OWASP Top 10-aligned risks: broken access control, injection, authentication failures, and security misconfiguration. Address weaknesses before deployment.

  • Authentication & accessWho is authorized?
  • Untrusted inputWhere is it validated?
  • Sensitive dataWhat can be exposed?
Explore an illustrative finding

Secure LLM-powered features.

LLM security / For AI product and RAG teams

Inspect prompt injection, sensitive information disclosure, and improper output handling. Examine the permissions that determine what a model can access or trigger.

  • Prompts & retrievalSeparate data from instructions
  • Model outputValidate before use
  • Connected toolsLimit effective permissions
Explore LLM security checks

Check autonomous agent actions.

Agent security / For teams building autonomous workflows

Review autonomous decisions, tool execution, delegated permissions, and interactions with external systems. Look for paths to unintended or unauthorized actions.

Explore agent security checks
  • Delegated authorityLeast privilege
  • External actionsAuthorization at execution
  • Shared contextUntrusted input boundaries
Credential in changed linesIllustrative
+ API_KEY = "[REDACTED]"

Secret values are omitted from findings.

Deleting a key
doesn't close the door.

Look for exposed credentials in the change. If a secret is real, revoke or rotate it, then remove it from code. Deleting the line is not enough.

Security belongs
in the everyday diff.

From a developer's first local edit to shared standards across teams, make security part of how code changes.

Trace prompt injection and tool abuse.

Trust boundaries / For AI application and security engineers

Find paths where malicious instructions can influence a model or trigger unauthorized tool calls. Strengthen the input handling and authorization between them.

  1. Untrusted content
  2. Model instructions
  3. Tool authority
Trace an illustrative change

Protect secrets and personal data.

Sensitive data / For application and data engineering teams

Look for credentials, personal information, and other sensitive data exposed in application code or AI workflows. Review access controls and data handling, not just hardcoded secrets.

  • Credentials in the diffExposure & rotation
  • Personal informationAccess & disclosure
  • AI data flowsContext & output handling
Review credential handling

Make security part of routine PR review.

Everyday review / For development and platform teams

Use configured automatic reviews to surface application, LLM, agent, and exposed-secret findings during code review. Request a focused PR/MR pass when security is the question.

  • Application, LLM & agent codeSecurity risks in the change
  • Changed linesExposed credentials
See commands and availability

Review AI-generated code before merge.

AI-assisted development / For teams scaling coding agents

Apply the same scrutiny regardless of who wrote the code. Look for vulnerabilities that fast implementation can miss, especially in changes involving LLMs, agents, or external tools.

DeveloperCoding agent
Same scrutiny
Review before the merge

Act while the change is still fresh.

Early remediation / For developers working on the change

Get a file, line, severity, and explanation while work is under development. Choose a remediation, test the vulnerable path, and address issues before they reach production.

From finding to safer direction
  1. Locate the findingFile, line, severity, and an explanation
  2. Choose a code changeRemediation stays with the developer
  3. Test the vulnerable pathCheck both allowed and rejected behavior

Apply consistent standards across teams.

Engineering governance / For security and platform leaders

Use shared rules and configured checklists across repositories, with expectations for application security, LLMs, agents, and sensitive data. Keep provider availability and host merge controls explicit.

Explore risk-based approval
  1. Shared expectationsAgree on security rules across teams
  2. Repository configurationApply the checks relevant to each codebase
  3. Provider controlsConfigure required checks separately

Make security part of your review policy.

Combine security findings with checklist policies and your host's required checks.

Policy & Risk-based Approval

One focused question.
Right where you work.

Ask CloudAEye to review the security of the change.
Keep the full code review for the broader picture.

Coding agent

Local changes, a path, or an eligible open PR

/cloudaeye:security
GitHubGitLabBitbucket

Pull requests & merge requests

Application, LLM, agent, and secret categories

@cloudaeye /security

Command details

Security review questions.

Where is the PR/MR command available?

Updated GitHub, GitLab, and Bitbucket integrations support @cloudaeye /security after their handlers and the code-review service changes are deployed. Use a GitHub PR conversation or inline review thread, a GitLab merge-request note, or a Bitbucket pull-request comment. Existing provider credentials, report permissions, and result-delivery setup still apply.

How is this different from /review?

/security focuses on application security, LLM security, AI-agent security, and secrets in changed lines. It uses the same review flow as /review, with security categories selected.

Can I review just the sensitive part of a change?

In your coding agent, add a file or directory, such as /cloudaeye:security src/auth/, to review changed code in that path. See the security guide for modes, severity filters, and PR eligibility.

Make the next change
a more informed one.

Start with 50 free reviews per month for individual developers. Plan details

Start free Security docs