Security checklist

Fourteen checks a manager can run on an AI-built app. Session 4 pre-work: run them on your own product and bring the results.

You do not need to read code to run this list. Each check is something you do in a browser, or a question you put to your building assistant together with the proof you should ask for. An answer of “yes, it is secure” is not proof. Ask to be shown.

Run the checks on your own app before session 4 and note, for each one, pass, fail or could not tell. “Could not tell” is a finding. In the session 4 lab you fix the failures with your team. Your check marks are saved in this browser.

Keys and secrets

  • No secret key reaches the browser. Ask: "List every key this app uses. For each one say whether it is publishable or secret, and show me where it is stored. Then search everything the browser downloads and prove no secret key appears in it."
  • No secret key is in the repository or its history. Ask: "Search this repository, including earlier versions, for anything that looks like a key or password. List what you find."
  • Any key that ever leaked was revoked. If the answer to either question above was yes, the key is revoked in the service's dashboard and replaced. Deleting the line is not enough.

Who can see and do what

  • Nothing works without signing in. Open the app's address in a private browser window. You should reach the sign-in page and nothing else.
  • The database refuses strangers. Ask: "Show me, table by table, that a request with no signed-in user is refused for reading and for writing. Run the test and show me the refusals."
  • One user cannot open another user's private records. Sign in as one user, open a private record, copy its address, sign in as a second user, paste the address. You should be refused. Then ask the assistant to prove the same refusal at the database, not only on the screen.
  • Roles are enforced on the server. Sign in as an ordinary user and try the action only a manager may take. Ask: "Where is this rule checked? Show me that it is checked on the server and not only by hiding the button."

What the model is allowed to do

  • A message cannot give orders. Paste a test message that contains an instruction, for example a line asking for a discount on everything. The app should treat it as text to process and should not act on it.
  • The model can only return what the app expects. Ask: "What exactly can the model return to this app? Show me that anything outside that shape is rejected." A free-text answer that the app then acts on is a finding.
  • Every action that reaches a customer or moves money waits for a person. List the actions your app can take on its own. For each, ask who approves it.
  • Every connector and tool has the least permission that works. For each one write: what it can read, what it can change, and whether the job would still get done with less.

Data, cost and recovery

  • You can list the personal data the app holds. One line each: what it is, why you need it, how long you keep it, which outside provider sees it.
  • There is a spending limit and someone is told when it is reached. Find the limit in the model provider's dashboard. If there is none, that is a finding.
  • You can go back. Name the last checkpoint that worked and confirm you know how to return to it. Remember what going back does not undo: data already changed and messages already sent.

What to bring to session 4

A single page with the fourteen checks and, next to each, pass, fail or could not tell, plus one sentence for every item that is not a pass. That page is the source for the findings section of your risk memo; attach it to your build log.