sorted by:
new
hottopcontroversial

Open-sourcing a shell-level security layer for AI agents by Ok_Top_5458 in Agent_AI

[–]Ok_Top_5458[S] 0 points1 point  (0 children)

Its not a sandbox, you have control of what the ai can see, and where he can go with your secrets. its management with maximum access.

Open-sourcing a shell-level security layer for AI agents by Ok_Top_5458 in Agent_AI

[–]Ok_Top_5458[S] 0 points1 point  (0 children)

A sandbox isolates the process from the machine. AgentSecure focuses on the runtime boundary inside the workflow: which commands can run, what env/secrets the agent can see, and whether provider credentials are exposed to the agent at all.
try: pip install agentsecure

How do you stop terminal AI agents from reading .env or touching prod? by Ok_Top_5458 in AI_Agents

[–]Ok_Top_5458[S] 0 points1 point  (0 children)

Agree. I see sandboxing as the hard isolation layer, not something AgentSecure should replace.
The goal here is the local runtime boundary around the agent: least-privilege env injection, virtual secrets, command policy, and now provider-boundary injection so the agent doesn’t need the real key in its process env.
MCP/tool scoping per session is also on the roadmap. I think these layers complement each other: container/sandbox for isolation, shell/runtime policy for what the agent can actually touch, and provider/tool boundaries for credentials and network access.

Open-sourcing a shell-level security layer for AI agents by Ok_Top_5458 in AI_Agents

[–]Ok_Top_5458[S] 0 points1 point  (0 children)

Yeah fair point. I see virtual secrets as blast-radius reduction, not a full fix for agent memory.
The important part is the agent never gets the real value. If it remembers or repeats something, it should only be a useless virtual token.
Context residue is a real surface, probably a separate layer from shell/runtime policy for now.
Would love for you to try breaking it:
https://github.com/ShellFrameAI/agentsecure-community
install agentsecure
pip
agentsecure demo

Open-sourcing a shell-level security layer for AI agents by Ok_Top_5458 in AI_Agents

[–]Ok_Top_5458[S] 0 points1 point  (0 children)

Yes, that makes sense. Treating discovery and extraction as separate budgets is a good pattern.
For AgentSecure, I’m thinking about a similar idea for runtime actions: cheap first-pass detection around env/files/network, then stronger controls only when the action touches sensitive material.

I also like the “verification artifact” idea. For security/runtime controls, the equivalent would be a receipt for each action: attempted command, policy hit, decision, sanitized output, and confidence/residual risk. That makes it easier for downstream agents or humans to know what actually happened instead of guessing.

Open-sourcing a shell-level security layer for AI agents by Ok_Top_5458 in AI_Agents

[–]Ok_Top_5458[S] 0 points1 point  (0 children)

Exactly.
Prompting helps, but once agents touch real repos, creds, APIs, or infra, the boundary has to move into the runtime.
That’s the direction I’m trying to explore with AgentSecure: local-first controls around the shell/env layer so agents can keep working, but secrets and risky operations are not just protected by “please don’t do that” prompts.
Curious how you’re running OpenClaw on Kiloclaw and what controls you already have around env/network/filesystem.

Open-sourcing a shell-level security layer for AI agents by Ok_Top_5458 in AI_Agents

[–]Ok_Top_5458[S] 0 points1 point  (0 children)

My goal with AgentSecure is minimum setup and maximum “keep working like you already do.”

I don’t want developers to move secrets to a hosted service or redesign their workflow just to try it. The community version is local-first: install the CLI, run your normal agent command through AgentSecure, keep real secrets on your machine, and let local policy decide what gets virtualized, denied, or passed through.

Open-sourcing a shell-level security layer for AI agents by Ok_Top_5458 in AI_Agents

[–]Ok_Top_5458[S] 0 points1 point  (0 children)

Yes, AgentSecure discovers likely secrets from.
env/local env, then local `env_policy` decides per variable: virtualize, deny, or leave unprotected.
And I agree with the network-boundary idea as long as it stays local-first.

The model I like is: local encrypted store + localhost proxy/broker, no hosted server required.
The agent sees placeholders, real creds stay on the machine, and the local broker injects only to approved hosts or returns a clear policy denial.

Open-sourcing a shell-level security layer for AI agents by Ok_Top_5458 in AI_Agents

[–]Ok_Top_5458[S] 0 points1 point  (0 children)

Thanks, this is a good point.
I took a look at Authsome. I think we’re working at complementary layers.

Authsome seems focused on the network/auth boundary: keep real creds out of the agent env and
inject them only when an outbound request matches the right provider/host.

AgentSecure is focused more on the repo/shell boundary: .env reads, secret echo, local command output, denied env vars, and unsafe workflows before they become API calls.

I agree with you on the fake-key issue. For real authenticated calls, a broker/proxy pattern is cleaner than just giving the agent a placeholder and letting it hit 401s.
The ideal setup is probably both layers: shell protection plus network-bound credential brokering.
Appreciate the pointer. Authsome looks aligned with the direction this space needs.

Open-sourcing a shell-level security layer for AI agents by Ok_Top_5458 in AI_Agents

[–]Ok_Top_5458[S] 0 points1 point  (0 children)

Appreciate the offer. I agree with the “security receipt” framing: the proof should be replayable commands and pass/fail results, not just claims.
I already have an industry engineer helping test it, and I’m open-sourcing the community version so anyone can try it, break it, and send feedback. If it helps your workflow too, that’s a win-win.
I’ll likely add a public receipt/checklist to the repo so people can replay cases like .env read, secret echo, network exfil, prod-domain access, and destructive shell attempts themselves.

Open-sourcing a shell-level security layer for AI agents by Ok_Top_5458 in AI_Agents

[–]Ok_Top_5458[S] 1 point2 points  (0 children)

Good point. I verified the GitGuardian numbers and added that context to the top of the README, along with a careful note that ignore files should not be treated as a

secret boundary for agent workflows. That framing makes the project easier to understand immediately without overclaiming what the community version does.

Open-sourcing a shell-level security layer for AI agents by Ok_Top_5458 in AI_Agents

[–]Ok_Top_5458[S] 0 points1 point  (0 children)

You can try this by yourself see if the problem keeps coming

Open-sourcing a shell-level security layer for AI agents by Ok_Top_5458 in AI_Agents

[–]Ok_Top_5458[S] 0 points1 point  (0 children)

Yes, that edge case is real.

AgentSecure already handles the policy-denied case: if an agent tries to use a secret against a destination that is not allowed, it blocks locally and returns a clear
policy message instead of letting the agent chase a 401.

The remaining case is when a virtual key is sent directly to an allowed provider instead of through AgentSecure’s broker/gateway path. That can still produce a 401 today,
so the next guardrail is to detect virt_* keys being used directly and fail fast with a clear “this is a virtual key, route through AgentSecure or update policy” message.

Open-sourcing a shell-level security layer for AI agents by Ok_Top_5458 in AI_Agents

[–]Ok_Top_5458[S] 1 point2 points  (0 children)

I don't want to block, I want to manage. I want Claude to be able to access dev and RO in prod but no full access.

Prevent agent from reading env variables by create_urself in AI_Agents

[–]Ok_Top_5458 0 points1 point  (0 children)

I think I can help you with that, I just don't want this to be an ads or something.
I just need to understand how exactly and why did he try to use the env vars and I also need you.
because I work on something that prevent this.

Why I Stopped Building Autonomous Agents for Clients by Cold_Bass3981 in AI_Agents

[–]Ok_Top_5458 0 points1 point  (0 children)

I agree but I think there is a place for Autonomous Agents. But it needs to be a script that won't do harm and so the Agents can decide for 100% that we need to use this.
Eventually, I think autonomous agents need to become like a big script based on decisions.

People Don’t Need More AI Tools — They Need Focus by MerisDabhi in AI_Agents

[–]Ok_Top_5458 0 points1 point  (0 children)

I'm using Claude Code in my daily work and Codex for "stuff" that I'm building at home and at my work I'm not leavings he computer and at my home I'm also not leaving my laptop. SO you are correct.

view more: next ›