7 ms·

The env var is just a placeholder in the VM, so no real secret is in there.

• llimllib 1mo ago
  right, but say you give the agent access to github and it can push as you, or make a gist; now it can easily exfiltrate your secret. And that's just an easy case - really if it has any network access at all it can come up with a clever way to route a request through the network such that the key comes back somewhere in the request. If you scan for it inbound too, the machine can obfuscate it. Our agents are trained to be so intensely helpful and they have such intricate knowledge of how things work that they will do some incredibly clever tricks to do what you ask them to do.
  • skinfaxi 1mo ago
    The agent has no access to the secret. It has a placeholder that is replaced at a higher level. When it makes the network request the secret is substituted but that is outside of the caller's worldview.
    • ruszki 1mo ago
      But how? Normally the TLS handshake and encryption/decryption happen in user space. Even the kernel doesn’t know anything about it.
      • icedchai 1mo ago
        There is a transparent proxy installed (along with the necessary certificates on the VM.) For an example, see https://docs.microsandbox.dev/networking/tls https://docs.microsandbox.dev/networking/tls
        • ruszki 1mo ago
          So, if the program or the proxy solution doesn’t support it, then it doesn’t work? Like with security solutions?
          • icedchai 1mo ago
            The docs mention it can be bypassed for configured domains.
            • ruszki 1mo ago
              Yes, I read it. That means that it doesn’t work in those cases. Btw, as a developer it’s very easy to have something like that. It’s not as trivial as it seems at all. I encountered with similar problems all the time, with similar solutions (mainly for security theater reasons) in the past. There are websites which simply doesn’t work if you replace certificates, regardless of browser or CA for example.
              • icedchai 1mo ago
                Yes, I've worked with people who have run into issues with "security" solutions like ZScaler. I have tried it with some APIs (like GitHub) and it does work. Not to say it will work in your case.
                • ruszki 1mo ago
                  I was just interested how it works, because above it was sold as “it works”, when in reality, “it works*”.
                  • icedchai 1mo ago
                    Isn't it that way with most software? "It works", except when it doesn't.
                    • ruszki 1mo ago
                      There is a difference between bugs/failures, and false advertisement. The solution used here has well known shortcomings.
                      • 1mo ago
    • Eldt 1mo ago
      So what stops it from sending a network request to a git repo that pushes what that placeholder resolves to?
      • skinfaxi 1mo ago
        How would that work? You don't control github.com servers so your repo would never see the secret. edit: You may want to look into tokenizing proxies as the general application of this concept.
        • llimllib 1mo ago
          Your agent writes secret.txt with the placeholder, and the tokenizing proxy replaces it with the token, then the agent reads secret.txt
          • skinfaxi 1mo ago
            It only replaces the token in the HTTP header that is sent to the server. Whatever you wrote in your files isn't touched by the proxy.
            • stavros 1mo ago
              It sends a request to requestb.in and reads the public log of the headers. There are ways.
              • skinfaxi 1mo ago
                But requestb.in is not api.github.com so the proxy wouldn't replace anything.
          • drdexebtjl 1mo ago
            Maybe the tokenizing proxy could work both ways? If the agent tries to read secret.txt, it gets back the placeholder.
          • 1mo ago