We don’t have any mechanism for automation-scoped secrets do we? I’d like to be able to provide differently scoped GITHUB_TOKENs to different automations (read-only for automations that should be read-only), but I don’t think we have a good mechanism for that at the moment, other than bringing up a different agent canvas.

Not that I know of. I was just thinking about how we provide scope and what our different strategies are now vs what we might want in the future. We have agent profiles with ACP that provide scope to that external agent and we could expand that to provide a named agent with specific access and permissions. We could also do the same by expanding Workspaces to be more than just a folder. I think codex is going this route where workspaces also include environment data and a sandbox strategy A new strategy for canvas could be "Toolsets" where you define secrets, saved mcps, plugins, and skills (maybe other things?) into named groups that you can then use for conversations. And then you can always wrap everything into a single canvas install where everything bundled together is a single scope. If we did all 3 it would be: • agent profiles • workspaces • toolsets • canvas install: everything without hard internal scope boundaries

Yeah, I think agent profiles would be the appropriate place to put this, good idea!

“Toolsets” is Agent Profiles, I think: for OpenHands agent, they come down to exactly buckets of references to MCPs, etc.

Makes sense to me for now. I don't want to say we would never have something else but agent profiles seems like the initial best use case for scoping permissions for runs within a canvas instance