Every week my feed is full of autonomous agent swarms running 24/7. Meanwhile, enterprises are still leaving private keys and database passwords in Git repos. Before you give another agent production access, make sure someone has handled: > private keys and database passwords kept out of source code, including private repositories > secrets kept out of Slack messages, support tickets and AI chat history > backend credentials kept out of the JavaScript every visitor downloads > a secrets manager where access to one application's credentials doesn't reveal everybody else's > push protection that blocks detected secrets before they reach the repo, with bypasses reviewed > secret scanning that checks Git history, because deleting the file leaves the old commits > secret checks on container images and build artifacts, because a clean repo doesn't mean a clean release > revoking exposed credentials and checking that sessions and tokens already issued from them can no longer access the system > short-lived credentials wherever the infrastructure supports them > a way to rotate the remaining long-lived keys without taking the application down > separate credentials for development, staging and production > a named owner for every service account, integration and API key > removing the credentials for the experiment everyone abandoned six months ago > download links limited to the intended file, with an expiry > individual admin accounts, so the audit log can identify an actual person > phishing-resistant MFA for human access to email, Git, cloud consoles and privileged accounts > the forgotten test account covered by the same security requirements > account recovery that doesn't let a convincing phone call bypass MFA > temporary elevated access that expires when the work is finished > offboarding that revokes sessions, tokens and SSH keys as well as the employee's login > contractor access that ends when the contract does > access reviews where someone actually removes permissions > tested emergency access that still works when normal sign-in fails, with every use logged and alerted > permissions that deny access unless it has explicitly been granted > a reporting service that can read the database without being able to delete it > an invoice integration that doesn't need administrator access to the entire cloud account > OAuth permissions limited to the job the integration actually performs > access tokens whose signature, issuer, audience and expiry are actually checked > authorization checked on the server for every request > checks that stop one customer reading another customer's invoice by changing the ID > the same customer isolation in search, exports and file downloads > tests that prove forbidden actions fail > production databases and admin interfaces restricted to the access paths they actually need > customer documents in storage that isn't accidentally public > separation between test and production, so compromising a demo doesn't unlock the business > deployment credentials scoped to the application being deployed > untrusted pull requests kept away from production secrets > reviewed, locked versions of the third-party code running inside the deployment pipeline > approval required for changes to the pipeline and its security rules > logs that record access and permission changes without recording the credentials themselves > audit records the application cannot quietly erase after it has been compromised > alerts for new privileged accounts, suspicious logins and unusual data exports > backups protected by permissions that stop a compromised production account deleting them too > a restore someone has actually tested > a recovery plan for compromised signing and encryption keys, including the data and tokens they protected > a person responsible for patching exposed systems and vulnerable dependencies > AI agents with identifiable accounts and access limited to their assigned work > permission checks that stop an agent using its service account to fetch data the requesting user cannot access > production credentials kept out of the agent's prompts, files and shell environment, with authenticated operations handled by a restricted execution service > tool permissions enforced by code outside the model > outbound network access limited to approved destinations > tests for malicious instructions in documents, tickets and tool responses the agent reads > single-use, expiring approvals tied to the person, action, target and parameters, checked immediately before execution > an agent that cannot grant itself more permissions or approve its own request > limits on tool calls, bulk exports and spending, so a permitted action cannot repeat without a ceiling > a tested way to stop the agent and revoke its access > independent verification of urgent payment or access requests through a known, trusted channel, even when the voice sounds exactly like the CEO Oh, and someone still has to own this after launch: > deciding who needs access > removing it when the job changes > investigating the alerts > fixing what the scans find > checking that the fix actually works > answering the phone when production is compromised Your agent swarm may work 24/7. So does the production key nobody revoked. We go into enterprises with working, profitable software and still find ridiculous security holes. Book a call with us if you need enterprise AI implementation done the right way.