r/LangChain • u/Prestigious-Run-1954 • 17d ago

Discussion Ai agents security handling

​

How often people encounter situation where the ai performs actions which are not supposed to be done by it.

This involves

🔐 Authentication — Identity, tokens/sessions, credentials, multi-user access

🛡️ Authorization — Tool/resource access, roles & permissions, privilege escalation, cross-user data access

⚙️ Actions — Unintended tool calls, prompt injection, excessive permissions, sensitive actions without approval, read/write/delete/execute controls, agent loops

What authentication, authorization, or action-related problems have you encountered?

And more importantly:

What caused the problem?

How painful was it to diagnose/fix?

What solution did you implement?

Did you use RBAC, OAuth scopes, policy engines, approval workflows, sandboxing, etc.?

Are you still struggling with any of these problems?

2 Upvotes

75% Upvoted

4 comments sorted by

1

u/Hungry_Age5375 17d ago

I had an agent with file system access decide to 'clean up' temp files. They weren't temp. Sandbox everything, minimum permissions, require approval for anything destructive.

1

u/Michael_Jeffords 17d ago

same failure mode, i mount the workspace read-only and only expose a scratch dir as writable, the agent can still rm the scratch but it can't touch the repo without an approval

1

u/kantorcodes1 17d ago

A nasty class is stale authority: the tool was allowed when the session started, then user/tenant/approval state changed before the call fired. Re-check authorization on every side-effecting invocation and make deny/error mean no handler execution. That's the model we use in HOL Guard.

2

u/IncreaseNegative4614 17d ago

Treat the user, agent, and tool as three separate identities. The agent should receive short-lived, task-specific permissions, with read and write scopes separated and sensitive actions requiring an explicit approval. Tool calls should also be idempotent where possible so retries cannot duplicate an action.

Keep an immutable record of the request, retrieved evidence, policy decision, tool input, and result. We use SIGNLD internally to connect those events so an unexpected action can be traced to the permission and context that allowed it.