Summary of the new feature / enhancement
I reckon with the mixed use of developing that goes in with windows and system administration. it could be a benefit to allow (with group policy overriding/disabling/enabling behavior) ssh-agent and ssh-add to be tied to terminal scope... so that instead of running ssh-agent and ssh-add as a global user scope... your terminal could be configured to launch 2 profiles; One that uses the user's ssh-agent daemon(as it currently is). OR to launch the shell sandboxing ssh-agent in the profile as a child process. This would also allow scripts running on the computer to not be able directly access all the keys in the global user scope...
Proposed technical implementation details (optional)
One could envision this as an extension of sudo or windows sandboxing, depending on your ecosystem, where the on systems where its enabled... the user global scope (path and sockets/pipes) would either be left open and accessible to all processes.. or the system can launch powershell with its handle controlling the child ssh-agent process (potentially using windows sandboxing or like it on the default pipe/socket path used by ssh-agent), allowing any exposed keys to be limited to that terminals scope
Summary of the new feature / enhancement
I reckon with the mixed use of developing that goes in with windows and system administration. it could be a benefit to allow (with group policy overriding/disabling/enabling behavior) ssh-agent and ssh-add to be tied to terminal scope... so that instead of running ssh-agent and ssh-add as a global user scope... your terminal could be configured to launch 2 profiles; One that uses the user's ssh-agent daemon(as it currently is). OR to launch the shell sandboxing ssh-agent in the profile as a child process. This would also allow scripts running on the computer to not be able directly access all the keys in the global user scope...
Proposed technical implementation details (optional)
One could envision this as an extension of sudo or windows sandboxing, depending on your ecosystem, where the on systems where its enabled... the user global scope (path and sockets/pipes) would either be left open and accessible to all processes.. or the system can launch powershell with its handle controlling the child ssh-agent process (potentially using windows sandboxing or like it on the default pipe/socket path used by ssh-agent), allowing any exposed keys to be limited to that terminals scope