Would love to see your tiny agents project. But understand that it might contain something sensitive and will therefore stay private.
14 karma · joined January 20, 2024
Would love to see your tiny agents project. But understand that it might contain something sensitive and will therefore stay private.
Wardgate acts like a drop in replacement for curl with full access control at the url / method / content level, so you can allow specific curl access to specific APIs but prevent all other outbound connections. That's what I use for my PA agent. She's very limited and can't access the open internet. Doesn't need it either
Welcome to the age of selfware! Where everybody makes what they need! :)
It tries to do everything, but has no real security architecture.
Exec approvals are a farce.
OC can modify it's own permissions and config, and if you limit that you cannot really use it for is strengths.
What is needed is a well thought out security architecture, which allows easy approvals, but doesn't allow OC to do that itself, with credential and API access control (such as by using Wardgate [1], my solution for now), and separation of capabilities into multiple nodes/agents with good boundaries.
Currently OC needs effective root access, can change its own permissions and it's kinda all or nothing.
(It would help in other cases)
Definitely something that can be looked into.
Wardgate is (deliberately) not part of the agent. This means separation, which is good and bad. In this case it would perhaps be hard to track, in a secure way, agent sessions. You would need to trust the agent to not cache sessions for cross use. Far sought right now, but agents get quiet creative already to solve their problem within the capabilities of their sandbox. ("I cannot delete this file, but I can use patch to make it empty", "I cannot send it via WhatsApp, so I've started a webserver on your server, which failed, do then I uploaded it to a public file upload site")
To solve this I've built Wardgate [1], which removes the need for agents to see any credentials and has access control on a per API endpoints basis. So you can say: yes you can read all Todoist tasks but you can't delete tasks or see tasks with "secure" in them, or see emails outside Inbox or with OTP codes, or whatever.
Interested in any comments / suggestions.
So you would configure this:
endpoints:
calendar:
preset: google-calendar
auth:
credential_env: WARDGATE_CRED_GOOGLE_CALENDAR
capabilities:
read_data: allow
create_events: allow
update_events: ask
delete_events: ask
So updating or deleting events requires human permission.There are already time controls and rate-limiting included.
On the list for things to develop is an LLM model adapter as well, that could detect prompt injection, but also identity-masking and credential-triggering-approvals. Anomaly detection is on the todo.
The threat model is agents deliberately (because of gullibility, prompt injection, or dumb actions) leaking data and either detecting that early on or preventing such things.
I built Wardgate [1] because I wanted agents to access my calendar, tasks, e-mail and other services, but not by giving them my actual credentials or giving them full access.
For some services you can create API keys with limited scope, but most often API keys just get full capabilities.
Wardgate is a proxy: agents call Wardgate endpoints, Wardgate injects real credentials, enforces access rules, and logs everything. The agent never sees your keys.
Written in Go, easy to self-host. Has presets for common services (Todoist, GitHub, Gmail, etc.) and IMAP/SMTP adapters for email.
Happy to discuss the architecture or take feedback.
So you either have to stick to a vulnerable version or have no een UI.
This form seems to target just that. So for the UI kinda similar actually.
In my experience, this solves the sticky 301 issue and you should have no issues with cached 301s anymore.
Works perfect for these kind of investigations or if you made a mistake during site development.
From my experience with coding parts of Un-static [1], the advantage of having a single source for submissions for thousands of forms, is that you can filter out these more easily as well. As you can create partial fingerprints. Then just compare similarity between incoming submissions on other forms. And of course start blocking if you receive a scatter-gun message that matches partial fingerprints received across an increasing number of form endpoints.
I'm interested to hear what the advantage over Obsidian is?