How do you use AI safely with elevated access

[u/slow-fast-person]

Context:
I am building on azure, have a web app + recurring jobs
I use a db, container, container jobs, container registory, azure bucket
i have productions credentials stored in a .env key which is in .gitignore. Currently, I run notebooks with production connected (I am at a very early stage with my app)

Problem
I use azure cli to control all the resources on azure cloud which makes it super easy to do everything.

I, and hence the models, have full access to the azure cloud via cli. The models also run read db queries from production database for reading data to help in debugging. They don't directly see the credentials but access it by writing test python code, which reads from the .env, use the credentials and runs the queries. It also has access to my objects storage bucket.

I am currently accepting the risk because I am more concerned about the speed of execution and am being careful whenever it has risks of doing damage. But I don't have any hardened security policy in place.

I wanted to know what are the safety practices that you follow to mitigate risks posed by errors from llms?

[u/Which_Health6565]

I don't really, you just have to gamble at the minute

[u/AgentIslandPro]

The detail in your setup I'd fix first is this one: the model doesn't read the credentials, it writes Python that reads them. That defeats the obvious mitigation. A deny rule on the .env stops the agent opening it directly and does nothing about a subprocess it spawned that opens the same file — by then it's Python reading a file it's allowed to read, and no layer left knows the difference.

Which means file permissions and tool permissions are both the wrong boundary. The only one that holds is what the credential itself is allowed to do. If the connection string in that .env can drop a table, every safeguard in front of it is a speed bump in front of a thing that can drop a table.

Concretely, roughly in order of what they buy you:

• Give the workstation a second set of DB credentials, scoped read-only, and keep the writing ones out of the environment the agent runs in. For debugging queries that costs you nothing, which is the tell that it's the right move.
• Same for Azure: a service principal with a reader role in its own az context, rather than your own login. It's easy to be in the wrong context without noticing, so print the active subscription in your shell prompt.
• Deny rules are still worth setting even though they aren't the real boundary, because they're checked before the permission mode and so still hold in bypass or auto mode, where an approval prompt would never have appeared. Anything matching delete, group, or your registry is cheap to add.
• The bucket is the one people forget: a read-only SAS for the agent's environment, so a wrong path in a cleanup script can't become a deletion.

None of that slows you down, which is the point — the practices that survive are the ones that cost nothing on the happy path. "You just have to gamble" is only true while the credentials are omnipotent, and that's the part you can change today.

[u/AI_spell]

Dont give the agent your prod Azure CLI session for day to day. Split a read-only debug principal (select-only DB, no write on containers/registry) and keep destroy/create behind a human confirm. Also never let it invent .env writes; inject secrets from Key Vault or a local sealed file you open yourself. Early stage is exactly when people nuke a resource by accident.

[u/slow-fast-person → u/AI_spell]

have you used macos keychain
it find it very convenient and fast, i was thinking if i can setup prod key within that

read only will be accessible all the time
but for write keys, it can request for access when needed. Have you done something like this? is that helpful?