[devendra116]

keyring is one of solution but even substituting values at excution does not gaurantee the security as agents can read the process itself.

im building a safe agent execution layer, A runtime where agents can act, but cannot access secrets. kinda sidecar that is callable by agent for using api keys, secrets, private keys, etc and plus one can add policy on how and what a agent can do.

does this seems good?

[10keane]

yah keyring is more for static protection. when the agent process itself is hostile, keyring is kinda obsolete.

but then i think the key is that sometimes agent does need access to credentials to be useful - like i will give some credentials to agent such as my browser account access.

personally i feel it is not really about preventing agent from accessing credentials, but more to have the supervision layer when agent access it - like you know exactly when and why agent need to access it and you have the ability to deny or approve it.

[devendra116]

so do we need something like `safe agent execution layer - that is policy enforced` (SEAL) we can manage what should be allowed and what not

agent uses llm to plan the action, but the actual execution happens in SEAL.

any example where it would make sense to start with?

open for thoughts

[10keane]

yah man i saw your project on the execution layer. i think it is great. but one thing i notice in my daily usage is that i am not sure what to allow or deny before the actual usage. like personally i am not able or interested in pre-setting policies. like claude code, you never know what agents want to call before the actual tool use - could be curl, bash, a random command for a random solution to a random problem. so i believe this supervision needs to be at runtime instead of preset