Show HN: Integrations gateway for agents with 2FA for destructive ops (OSS)
github.comHey HN!
I've been wanting to use something like OpenClaw for a while but couldn't get myself to give it access to anything important due to all the risks involved. Prompt injection is still a problem (even though some people seem to ignore it) and so are hallucinations and mishaps that cause agents to do things like delete production data [1].
Even harnesses like Claude Code and Codex are subject to this, particularly since we're getting progressively looser about how we run them e.g. Conductor is really popular and runs agents without any sandboxing.
That means we're in a bit of an all-or-nothing situation. There are people who just ignore the risks and connect everything to their agents and reap benefits from it while being subject to more risk, and there are others that just don't connect anything because they are mindful of the potential issues.
I've been quite cautious but have wanted to run more autonomous agents and so I built the component I needed to enable me to do so: AgentPort.
AgentPort is a gateway that connects to any service (e.g. Gmail, GitHub, Stripe, PostHog, Linear) and let's you set granular permissions for what the agent can do automatically, what it needs your approval for, and what it can never do.
For example, you can set `list_customers` and `get_customer` on the Stripe integration to "Auto-approve" but `create_refund` to "Ask for approval". The agent will thus be able to do a lot in the background independently but when it comes to a potentially destructive operation it will be blocked and receive an approval link to send to you. You can then approve or deny the call with those exact parameters e.g. `create_refund(customer_id: 1234, amount: 12)`.
Agents connect via MCP or CLI and have access to all the integrations you connected without ever getting API keys. Kind of like Composio but with granular permissions and open source.
The goal with AgentPort is to specifically address two vulnerabilities that agents are subject to:
1. Destructive operations on downstream services: It can't delete a database unless you explicitly approve 2. Credential exfiltration: Your agent never sees API keys
AgentPort also helps with sensitive data exfiltration, but that is more nuanced and complicated to defend against if the agent has an internet connection [2].
Ultimately, AgentPort was the missing piece for me to start running more autonomous agents that have access to third-party services, and hopefully it can unlock use cases for you too. There's a ton more work needed around securing agents (Claws in particular) and I've both been writing about it [3] and intend to do more in this space, so if you're thinking about similar things let's have a chat.
The repo is https://github.com/yakkomajuri/agentport and you can run it locally with docker compose in a minute or use the one-liner install to deploy a prod instance (domain, TLS, etc.) in just a few mins as well.
[1] "An AI agent deleted our production database. The agent's confession is below" (https://news.ycombinator.com/item?id=47911524)
[2] See my post "On agents dropping production databases": https://yakko.dev/blog/on-agents-dropping-production-dbs
[3] https://yakko.dev/blog Hey...interesting idea and definitely trying to solve a legit problem. With the human-in-the-loop aspect of it, is there any timeout or retry logic? Otherwise, the agent's sitting there blocked waiting on you. Yeah so this is the part where it needs to be tested actively by more people in order to design the best experience. So today there are two modes: 1. The agent halts and waits for you to approve 2. The agent can fire the tool calls and keep working on other things and only at the end ask for the approvals it needs It's not perfect, but it does work well in a lot of cases. Retrying is pretty simple because you can just tell the agent to re-run the same tool call and approve it then. As of right now approvals expire within 15min but I'm actually putting a PR up today to make this configurable. Adding a human in the loop technically does limit how much can be done fully autonomously (e.g. via scheduled agents) but: a) I think the tradeoff is worth it b) it gives me peace of mind to let agents run unsupervised on a schedule for tasks that shouldn't require approval because I know they won't do something they weren't instructed to do when left unsupervised. Nevertheless, it's a tricky design problem. I prefer the current approach to having to log into AgentPort and approve things from a "pending approvals list" there, but what do you think? What would make most sense to you?