3 ms·

This isn’t a normal software bug, it’s not fixable in the same way you can’t fix regular support staff from being tricked. The answer is you should not allow L

This isn’t a normal software bug, it’s not fixable in the same way you can’t fix regular support staff from being tricked. The answer is you should not allow LLMs access to untrusted input and sensitive data at the same time.

valleyer 4mo ago
Your second paragraph directly contradicts the first.
- LoganDark 4mo ago
  Since you cannot fix information leakage from LLMs, you must remove the information so that it cannot be leaked. There is no contradiction there.
  - valleyer 4mo ago
    Right, that's the fix. So saying that it's not fixable is incorrect.
    - deleted 4mo ago
      [deleted]
    - Gigachad 4mo ago
      The LLM is not fixable. Deleting the LLM or crippling it to the point of being useless isn't fixing the bug.
      - crote 4mo ago
        Why not? If Ford puts a button in their car which blows it up when you press it, removing the button fixes the issue. If your LLM implementation is fundamentally insecure, you'll have a giant gaping security hole until you remove your LLM implementation. The alternative is arguing that having the LLM is worth routinely leaking all your code and secrets and occasionally giving complete strangers full access over your repos. Somehow, I think that's going to be a hard sell.
        jakewins 4mo ago
        Right, except the researchers are the ones that added the button, pressed it and now are upset at Ford, in your example. GitHub agents don’t have access to unrelated private repos by default, nor respond to public issue comments by default. The researchers manually configured the agent to have access to unrelated private repos and also process untrusted public comments.
      - Austiiiiii 4mo ago
        This is some very weirdly loaded language for a discussion about security. Applying the same RBAC controls that should be restricting all human requests in a system is not "crippling ... to the point of being useless." There isn't a world where granting a layer of the stack the ability to bypass hardcoded security limitations is a value add.
    - deleted 4mo ago
      [deleted]
    - antonvs 4mo ago
      It’s not fixable by GitHub, which is what the original comment was asking about.
  - rileymat2 4mo ago
    There is a major contradiction depending on the definition of “support staff” and the role of the llm in the system which may need access to sensitive data or systems to perform its functions.
  - darkvertex 4mo ago
    Exactly. The system should run in a forcibly limited scope of the current repo only or add permissions for scope to include other org/user repos. It can't leak a private repo if it can't open it to begin with.
- antonvs 4mo ago
  The point is that Github can’t fix it. It’s the user’s responsibility to not grant access to accounts that shouldn’t have access to the resources in question.

valleyer 4mo ago

Your second paragraph directly contradicts the first.

LoganDark 4mo ago
Since you cannot fix information leakage from LLMs, you must remove the information so that it cannot be leaked. There is no contradiction there.
- valleyer 4mo ago
  Right, that's the fix. So saying that it's not fixable is incorrect.
  - deleted 4mo ago
    [deleted]
  - Gigachad 4mo ago
    The LLM is not fixable. Deleting the LLM or crippling it to the point of being useless isn't fixing the bug.
    - crote 4mo ago
      Why not? If Ford puts a button in their car which blows it up when you press it, removing the button fixes the issue. If your LLM implementation is fundamentally insecure, you'll have a giant gaping security hole until you remove your LLM implementation. The alternative is arguing that having the LLM is worth routinely leaking all your code and secrets and occasionally giving complete strangers full access over your repos. Somehow, I think that's going to be a hard sell.
      - jakewins 4mo ago
        Right, except the researchers are the ones that added the button, pressed it and now are upset at Ford, in your example. GitHub agents don’t have access to unrelated private repos by default, nor respond to public issue comments by default. The researchers manually configured the agent to have access to unrelated private repos and also process untrusted public comments.
    - Austiiiiii 4mo ago
      This is some very weirdly loaded language for a discussion about security. Applying the same RBAC controls that should be restricting all human requests in a system is not "crippling ... to the point of being useless." There isn't a world where granting a layer of the stack the ability to bypass hardcoded security limitations is a value add.
  - deleted 4mo ago
    [deleted]
  - antonvs 4mo ago
    It’s not fixable by GitHub, which is what the original comment was asking about.
- rileymat2 4mo ago
  There is a major contradiction depending on the definition of “support staff” and the role of the llm in the system which may need access to sensitive data or systems to perform its functions.
- darkvertex 4mo ago
  Exactly. The system should run in a forcibly limited scope of the current repo only or add permissions for scope to include other org/user repos. It can't leak a private repo if it can't open it to begin with.
antonvs 4mo ago
The point is that Github can’t fix it. It’s the user’s responsibility to not grant access to accounts that shouldn’t have access to the resources in question.