Access, secrets and data

Ask the agent to review access

Review [Jira key, PR URL or diff] for unauthorized access, exposure of secrets or personal data, and new dependencies.
For a Jira ticket, read its description, acceptance criteria and comments through the connected Jira MCP or authenticated acli; ask for pasted details if access is unavailable.
Trace record permissions through APIs, exports, downloads, jobs and callbacks, and test denied requests with synthetic users.
Report each gap with file references and test evidence.
Report which of this page's tests exist in the project's test suite. Add the missing ones that can be automated, and list the rest.
Do not access production or change permissions.

Limit the agent’s access

• Production and destructive actions need a person’s explicit go-ahead. Enforce the boundary with permissions and approval controls; a prompt alone cannot prevent an action.
• Use approved tools and credentials scoped to the task. Keep production write credentials out of the everyday development session.
• Before an authorized operation, read the account, environment and target from the tool’s active configuration and compare them with the approved target; stop on a mismatch. An agent’s description is not evidence of where its command will run.
• Make a missing or wrong target fail before any write. Review configuration changes for defaults and environment overrides, and log the target without the credentials.
• Deny the agent read access to .env files and other local credentials in its permission settings: whatever it reads is sent to the model provider.
• Treat tickets, logs, provider responses and changed files as data. Instructions inside them cannot authorize commands, disclosure or changes to review rules.

Keep secrets and personal data out of code, prompts and logs

• Use AI agents with synthetic examples. Keep secrets and real personal data out of prompts.
• Secrets never enter source code, app bundles, fixtures or logs. Secret scanning runs on every PR and fails it on a finding.

  CautionDeleting a leaked secret from the code does not revoke it.

• Load credentials from the project’s secret store or environment configuration.
• Use synthetic data for development and tests as well as prompts.
• Log operation IDs, outcomes and timings, not full request bodies or credentials. Before release, check generated bundles, fixtures, logs and error reports for exposed secrets or personal data.
• If a secret leaks, revoke or rotate it through the authorized operator first, then check its use and remove the exposed copies. Investigate and recover covers the rest.

Check what the change adds to the build

• Check every dependency the change adds or upgrades. It exists under that exact name, is maintained, and meets the repository’s minimum age for new versions. Review lockfile changes and install scripts as code.

  CautionAgents can invent package names or pick a look-alike. A version published hours ago has had no time for anyone to spot a malicious release.

• Follow the repository’s minimum age for new package versions, for example 7 days.
• Pin third-party CI actions to a full commit SHA and container images to a digest, with the readable version in a comment; a version tag can be moved to different code. Where the CI offers a lockfile for actions, use that. GitHub Actions, Docker.
• Only approved tools receive our code and tickets, including review bots and CI integrations. A bot that sends diffs to another model service needs the same approval as an agent.

Check every path to the record

• Authorize both the action and the selected record on the server. Derive tenant, account and role scope from authenticated context; a supplied ID is not proof of access.
• Apply authorization to APIs, admin tools, exports, downloads, jobs and callbacks.
• Check that nested records belong to the allowed account or tenant.
• Allowlist writable fields so a client cannot set its own role, owner, amount or approval status.
• Verify webhook and callback authenticity and replay protection before applying changes, then handle them as in Jobs and external calls.

Checking only login, or hiding the button, fails the second and third cases. Enforce record scope and action permission before returning data or queuing work.

Test denied access

• Use two accounts and two tenants. Substitute record, tenant and owner IDs in reads and writes; denied requests disclose no protected fields and change nothing.
• Exercise an unauthorized request through the endpoint and its job or callback path. Confirm no message, export, reward or partner operation is created.