Feat: Add prompt injection detection settings UI + update logging

[dorien-koelemeijer]

PR Description

UI configuration for prompt injection detection

Allow users to enable prompt injection detection and the confidence threshold through the UI instead of having to manually update goose config file.

Update security logging

• Noticed that security findings didn't get assigned a unique id (😱), so fixed that (SEC-{uuid})
• User decisions (allow/deny) are logged with this finding ID for easier log analysis

Some general cleanup

Remove some unnecessary/unused code

[DOsinga]

I had a quick look, but I fear this feels rather vibe codey - there's some duplication, unrelated changes, I wonder if you could do a bit of a review more yourself?

[dorien-koelemeijer]

I had a quick look, but I fear this feels rather vibe codey - there's some duplication, unrelated changes, I wonder if you could do a bit of a review more yourself?

You're right, I wanted to get it done too quickly. Having another look now and will do some cleanup. Thanks for the comments

[michaelneale]

looks like linting issues now

[michaelneale]

so the config is now saved as:

security_threshold: 0.2
security_enabled: true

not in a security: section - is that expected? (also I noted it didnt' save the threshold until I changed it, which I assume means default?)

@dorien-koelemeijer there are a few other changes not GUI related, what is best way to check this is still healthy?

looks ok otherwise, @DOsinga happier with shape of code?

[michaelneale]

thread safety/oncelock stuff looks good too

[dorien-koelemeijer]

so the config is now saved as:

security_threshold: 0.2
security_enabled: true

not in a security: section - is that expected? (also I noted it didnt' save the threshold until I changed it, which I assume means default?)

@dorien-koelemeijer there are a few other changes not GUI related, what is best way to check this is still healthy?

looks ok otherwise, @DOsinga happier with shape of code?

It'll be security.threshold: xx and security.enabled: true/false. But I think most people will just go through the UI settings now, since it's a lot easier.

Re: non-GUI related changes, you can simply test the changes in goose CLI/desktop version locally. I've tested until the last lint commit and everything was still fine - will do some final testing in the next couple of hours, but it should all be good.

[michaelneale]

@dorien-koelemeijer but when I saw it in the config.yaml - it wasn't grouped under security (was an underscore) - just wanted to know if that was expected?

[dorien-koelemeijer]

@dorien-koelemeijer but when I saw it in the config.yaml - it wasn't grouped under security (was an underscore) - just wanted to know if that was expected?

Really? Let me have a look as well 👀 In any case, I'll have to update instructions once this is merged. Would be great to get both this PR and the other one together in one release to prevent confusion

[dorien-koelemeijer]

@dorien-koelemeijer but when I saw it in the config.yaml - it wasn't grouped under security (was an underscore) - just wanted to know if that was expected?

Really? Let me have a look as well 👀 In any case, I'll have to update instructions once this is merged. Would be great to get both this PR and the other one together in one release to prevent confusion

I think I tried to keep things backwards compatible first and still had that config saved - you're right, it's definitely with underscores

Seems like it would make sense to keep underscores, since all config is saved like that? I guess it depends on whether this PR gets released at the same time as the other one, then we don't have to have things be backwards compatible. Honestly, probably easiest to keep it in line with all other config though and use underscores?

[dorien-koelemeijer]

so the config is now saved as:

security_threshold: 0.2
security_enabled: true

not in a security: section - is that expected? (also I noted it didnt' save the threshold until I changed it, which I assume means default?)
@dorien-koelemeijer there are a few other changes not GUI related, what is best way to check this is still healthy?
looks ok otherwise, @DOsinga happier with shape of code?

It'll be security.threshold: xx and security.enabled: true/false. But I think most people will just go through the UI settings now, since it's a lot easier.

Re: non-GUI related changes, you can simply test the changes in goose CLI/desktop version locally. I've tested until the last lint commit and everything was still fine - will do some final testing in the next couple of hours, but it should all be good.

Have tested both desktop and CLI version - all seems fine still. Testing will be the same as for the other PR if you wanted to give it a go as well to be safe

[DOsinga]

Looks much better, yeah! I think you can delete even more LLM comments - I always do