Odingard Security

The gap I keep coming back to is that agent identity and agent authority are fundamentally different problems. An agent can have a valid identity, legitimate credentials, and permission to access a system without having human authority to cause a particular consequence. That distinction becomes critical when agents can delegate work, move money, deploy infrastructure, or interact across organizational boundaries. I think the missing infrastructure is an enforceable chain connecting the human principal, delegated authority, exact action, execution boundary, and verified outcome. And it cannot be an optional authorization check inside the agent. If the agent still controls an unrestricted credential or execution path, the boundary can be bypassed. That’s the architectural problem we’re tackling with Guardian. I’m curious whether you see this emerging as an extension of traditional IAM or as an independent infrastructure category for autonomous systems. @atShruti insights.array.vc/p/agents-b…

Guardian isn’t an email guardrail. It’s human authority infrastructure for autonomous agents. Email is just one example. The same authority layer can govern an agent that wants to: • send or delete messages • make purchases or subscriptions • move money • call APIs or MCP tools • change cloud infrastructure • modify code or production systems • share sensitive data • delegate work to another agent • eventually control physical systems The pattern stays the same: Agent proposes an action → Guardian determines ALLOW / ASK / DENY → exact authority is bound to that action → execution happens → the result is verified and receipted. Guardian MCP is now live with 3 governed tools and a 99/100 trust score on MCPRush. If you’re building agents, MCP infrastructure, gateways, wallets, browsers, or execution platforms, I’d like to test where Guardian fits in your stack. @OpenAIDevs @vercel @composio @claudeai @mcprush github.com/Odingard/guardian…

A useful question came up today: What happens if an AI agent gets approval, then changes the action afterward? Example: You approve: “Send $90 to Vendor A.” The agent then tries: “Send $190 to Vendor B.” Guardian does not treat that as the same approval. The approval is bound to the exact action that was reviewed. Change the recipient, amount, resource, environment, or another protected field and Guardian evaluates it again. That means a human approval can’t quietly become broader authority after the fact. This is the difference between: “the user approved something” and “the user authorized this exact consequence.” #AI #AI_Agents

Guardian is live. AI agents can send email, spend money, call APIs and operate software. But access is not authority. Guardian puts human authority between the agent and the consequence. ALLOW / ASK / DENY. Try it: github.com/Odingard/guardian… ⭐ the repo if you believe autonomous agents need an independent authority layer.

Your agent's output should be a proposal, not an action. Guardian is the human authority layer for autonomous AI — every tool call gets an ALLOW / ASK / DENY before anything executes. Zero model calls in the decision path, 1,000+ tests behind it, signed evidence of every decision. Open-source SDK (Apache-2.0): npm i @odingard/guardian-sdk github.com/Odingard/guardian…

AI agents are getting smarter, more capable, and more autonomous. That isn’t the problem. The problem is deciding who has authority when the agent can actually do things. GUARDIAN is the human authority layer for autonomous AI. Intelligence can belong to the agent. Capability can belong to the agent. Execution can belong to the agent. Authority belongs to the human. Guardian is built to preserve that authority across intent, delegation, memory, protected data, tools, transactions, runtime trust, execution and proof. The real architectural test: If a completely new kind of agent appears tomorrow, can Guardian govern it without changing the authority kernel? It must. Because the future isn’t one assistant. It’s thousands of agents acting across every part of our lives. One human. Many agents. One authority layer. Open-source SDK (Apache-2.0): github.com/Odingard/guardian…

Soon a billion people will hand agents their lives. The problem isn’t that AI can act. It’s that access quietly becomes authority #OdingardSecurity #Guardian

Everyone wants 20 AI agents working for them. Almost no one is ready for what happens when those agents start acting on their own. Guardian is the authority layer that keeps them from becoming you. #AIAgents #AIOversight #AgenticAI #AISecurity @AnthropicAI

AI agents are starting to work across company boundaries. But there’s a problem: Who is the agent? Who does it represent? What is it authorized to say? And how does the other company prove any of it later? That trust gap is what we’re building Bifrost to close. #AgenticAI #Cybersecurity

I don’t think the next major problem in enterprise AI is making agents smarter. We’re already doing that. The harder problem is trusting them enough to let them act across organizational boundaries. Bifrost is our answer: Identity. Bounded authority. Verified answers. Signed receipts. The trust layer for autonomous organizations. #AgenticAI #Bifrost

We’re rapidly approaching a world where AI agents transact with AI agents. Here’s the part I think gets overlooked: An intelligent agent is not automatically a trusted agent. Identity ≠ authority. Authority ≠ unlimited access. And a conversation ≠ proof. That gap is where Bifrost lives. #AIAgents #AIInfrastructure

AI agents can already research, negotiate, buy, approve and act. But when one company's agent talks to another company's agent, there’s still a fundamental problem: Who is it? What is it authorized to do? Can I prove what it said? That’s the problem Bifrost is built to solve. #AgenticAI #Cybersecurity