zimbatm

Another aspect is access control.

CLIs live in the same namespace as the agent, so any secrets the CLI needs access to, the agent can also exfiltrate. And access control is lightly gated by the agent's tool call policy.

For an enterprise-level deployment, it becomes quickly desirable to have a centralized MCP backbone, on which each MCP is attached to. A place you can attach policies to, log activity, and reason about access control.

Maybe. This phenomenon of security holes being found closely to each other was also common before LLMs. People attention gets directed to a place and typically more issues are getting found.

Is there actual evidence coming from the Bun project itself?

Otherwise it's just FUD.

This is how keychains should be designed. Never return the secret, but mint a new token, or sign a request.

We need this also for normal usage like development environments. Or when invoking a command on a remote server.

Are you going to add support for services that don't support OIDC or this going to be a known limitation?

Isn't the point of OpenClaw that the agent can modify itself?

Thanks! Playing with packaging automation is actually quite fun.

Just added it to our inventory. For those of you using Nix:

    nix run github:numtide/llm-agents.nix#mistral-vibe

The repo is updated daily.

This should have been CONTRIBUTING.md all along.

The content of the AGENTS.md is the same as what humans are looking for when contributing to a project.

I haven't used it extensively, but it works. I don't think it necessarily needs any updates since the underlying tech is stable.