HN user

avoutic

14 karma

Interests: Cybersecurity, Entrepreneurship, Gaming, Hacking, Investment, Programming, Startups, Fintech, Legal Tech, Remote Work, Technology, Travel

Posts2
Comments18
View on HN

In the end it will all be about separation of duty between agents in a larger team and isolating the ones that need more access to your private stuff.

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

I think a lot of people, me included, fear OpenClaw especially because it's an amalgamation of all features, 2.3k pull requests, obviously a lot of LLM checked or developed code.

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.

[1] https://github.com/wardgate/wardgate

Author of Wardgate here:

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")

Hitting production APIs (and email) is my main concern with all agents I run.

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.

[1] https://github.com/wardgate/wardgate

WardGate also tackles "deleting all meetings"-kind of attacks, at least if you choose to. So for my setup, I allow calendar reading, but updating and editing, requires an approval by me.

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.

If you're using AI agents or LLM tool-use, you've probably pasted API keys somewhere you shouldn't or have them in the agent's environment.

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.

[1] https://github.com/wardgate/wardgate

MinIO gutted the UI recently. Actually fully removed it from the codebase.

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.

On Chromium-based browsers, if you open the Developer Tools (F12 or Inspect in right click) and you go to the Network tab, you can click 'Disable Cache'.

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.

Yeah the scatter-gun spam is different.

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.

[1] https://un-static.com