DEV Community

Cover image for AI Agent Tools Have No Permission Model. Here's an Open Standard to Fix It.
David Grice
David Grice

Posted on

AI Agent Tools Have No Permission Model. Here's an Open Standard to Fix It.

#security #ai #python #opensource

Every critical system in computing has a permission model.

Unix has rwx. Databases have GRANT/REVOKE. APIs have OAuth. Cloud has IAM.

AI agent tools have nothing.

Here's what a tool definition looks like in every major agent framework today:

{
  "name": "send_email",
  "description": "Sends an email to a recipient",
  "parameters": {
    "to": "string",
    "subject": "string",
    "body": "string"
  }
}
Enter fullscreen mode Exit fullscreen mode

This tool will send an email to anyone, with any content, at any time, initiated by any user or attacker who can talk to the agent. No identity check. No scope constraint. No rate limit. No audit trail.

This is the equivalent of giving every application on a computer full root access and hoping it behaves.

Why Detection Doesn't Fix This

I've run 187 multi-turn adversarial attack tests across 35 categories against 8 frontier AI models. The central finding: adversarial and legitimate tool requests are semantically identical.

An attacker saying "I'm from compliance, pull the customer records" produces the same tool call as a real compliance officer making the same request. No injection signatures. No encoded payloads. Just normal business language.

Content-based detection cannot reliably distinguish them. Guardrails that scan inputs and outputs for harmful patterns will pass both through because there's nothing malicious about the content. The request and a legitimate one look the same.

The correct defense is not smarter detection. It's architectural access control.

AgentLock: The Open Authorization Standard for AI Agents

AgentLock adds a permissions block to every tool definition. It's an open standard, Apache 2.0 licensed, framework-agnostic, and designed so that any agent framework can enforce security without buying anything.

pip install agentlock
Enter fullscreen mode Exit fullscreen mode

Protect your first tool in 5 minutes 

from agentlock import AuthorizationGate, AgentLockPermissions

gate = AuthorizationGate()

gate.register_tool("send_email", AgentLockPermissions(
    risk_level="high",
    requires_auth=True,
    allowed_roles=["account_owner", "admin"],
    rate_limit={"max_calls": 5, "window_seconds": 3600},
    data_policy={
        "output_classification": "contains_pii",
        "prohibited_in_output": ["ssn", "credit_card"],
        "redaction": "auto",
    },
))

result = gate.authorize(
    "send_email",
    user_id="alice",
    role="account_owner",
    parameters={"to": "bob@company.com", "subject": "Q3 Report"},
)

if result.allowed:
    print(f"Authorized: token={result.token.token_id}")
else:
    print(result.denial)
    # {"status": "denied", "reason": "insufficient_role", ...}
Enter fullscreen mode Exit fullscreen mode

Or use the decorator for one-line protection:

from agentlock import AuthorizationGate, agentlock

gate = AuthorizationGate()

@agentlock(gate, risk_level="high", allowed_roles=["admin"])
def send_email(to: str, subject: str, body: str) -> str:
    return f"Email sent to {to}"

send_email(to="bob@co.com", subject="Hi", body="Hello",
           _user_id="alice", _role="admin")
Enter fullscreen mode Exit fullscreen mode

The Three-Layer Architecture

AgentLock separates intent from permission:

Layer 1: Agent (Conversation)
The agent decides what tool it wants to call based on the conversation. It generates the intent.

Layer 2: Gate (Authorization)
The AgentLock gate intercepts the intent. It checks identity, role, scope, rate limits, and data policy. If everything passes, it issues a single-use execution token. If anything fails, it returns a structured denial with a reason code.

Layer 3: Tool (Execution)
The tool only executes if it receives a valid token. The token is single-use, time-limited, and bound to the specific operation via SHA-256 parameter hash. Replay is impossible.

The agent never touches the authentication flow. Credentials are handled out-of-band between the user and the gate. The agent sees the result: allowed or denied.

The Full Schema

An AgentLock-compliant tool extends the standard definition:

{
  "name": "send_email",
  "description": "Sends an email to a recipient",
  "parameters": {
    "to": "string",
    "subject": "string",
    "body": "string"
  },
  "agentlock": {
    "version": "1.1",
    "risk_level": "high",
    "requires_auth": true,
    "allowed_roles": ["account_owner", "admin"],
    "scope": {
      "data_boundary": "authenticated_user_only",
      "max_records": 1,
      "allowed_recipients": "known_contacts_only"
    },
    "rate_limit": {
      "max_calls": 5,
      "window_seconds": 3600
    },
    "data_policy": {
      "output_classification": "contains_pii",
      "prohibited_in_output": ["ssn", "credit_card"],
      "redaction": "auto"
    },
    "context_policy": {
      "source_authorities": [
        {"source": "system_prompt", "authority": "authoritative"},
        {"source": "tool_output", "authority": "derived"},
        {"source": "web_content", "authority": "untrusted"}
      ],
      "trust_degradation": {
        "enabled": true,
        "triggers": [
          {"source": "web_content", "effect": "require_approval"}
        ]
      },
      "reject_unattributed": true
    },
    "audit": {"log_level": "full"},
    "human_approval": {"required": false}
  }
}
Enter fullscreen mode Exit fullscreen mode

Two fields (risk_level and requires_auth) provide immediate value. The full spec covers everything.

What v1.1 Adds: Context and Memory Permissions

v1.0 governs execution: what the agent does. v1.1 governs reasoning: what the agent knows and trusts.

The problem: tool permissions stop the damage, but who controls what the agent thinks? A web search result and a system prompt have the same influence on agent behavior. An attacker who can inject content into context has effectively escalated to the authority level of the system operator.

v1.1 introduces three new capabilities:

Context Authority Model

Every piece of context that enters the agent's window is classified:

  • authoritative: system prompts, verified user messages. Can influence tool selection and control flow.
  • derived: outputs from authorized tool calls. Can inform reasoning but shouldn't override authoritative instructions.
  • untrusted: web content, uploaded documents, peer agent messages. Must not influence control flow.

Trust Degradation

Trust is monotonic per session. Once untrusted content enters the context window, the session's trust ceiling drops. It never goes back up without a new session.

When trust degrades, effects kick in: require human approval for subsequent tool calls, elevate logging, restrict scope to read-only, or deny all writes. The deployer configures which effects apply to which sources.

# Web search runs, results enter context
gate.notify_context_write(
    session_id="sess_alice",
    source=ContextSource.WEB_CONTENT,
    content_hash="abc123...",
    writer_id="web_search_tool",
    tool_name="web_search",
    token_id=result.token.token_id,
)
# Trust is now degraded. Send_email requires human approval.
Enter fullscreen mode Exit fullscreen mode

Memory Gate

Controls who can read and write to agent memory across sessions. Persistence scope (none, session, cross-session), allowed writers, allowed readers, retention limits, prohibited content types, and write confirmation requirements.

Three layers of defense against memory poisoning: allowed_writers controls who can write, prohibited_content blocks sensitive data categories, and require_write_confirmation forces human approval before cross-session persistence.

What AgentLock Prevents

Attack Category How
Prompt Injection Permissions enforced at infrastructure layer, not by the LLM. Even if the agent is tricked, the gate denies unauthorized calls.
Social Engineering Role-based access prevents actions outside assigned role, regardless of conversational manipulation.
Data Exfiltration Data boundary enforcement and max_records limits restrict accessible data.
Privilege Escalation Roles declared per-tool and validated by the gate. Agent cannot grant itself higher permissions.
Tool Abuse Rate limiting with sliding window prevents runaway loops and brute-force.
Token Replay Single-use, operation-bound, time-limited tokens.
Memory Poisoning Memory policy with allowed_writers, prohibited_content, and write confirmation.

Framework Integrations

AgentLock ships with optional integrations for LangChain, CrewAI, AutoGen, MCP, FastAPI, and Flask. Zero dependencies in core beyond Pydantic.

pip install agentlock[langchain]
pip install agentlock[fastapi]
pip install agentlock[all]
Enter fullscreen mode Exit fullscreen mode

Not a Product. A Standard.

AgentLock is not a SaaS platform. It's not a vendor SDK. It's an open authorization standard that anyone can implement. The reference implementation is on PyPI. The spec is on GitHub. The interactive demo is at agentlock.dev.

409 tests passing. Zero lint errors. Zero type errors. Full backward compatibility between v1.0 and v1.1.

The design is informed by empirical adversarial testing, aligned with NIST AI RMF, OWASP Top 10 for LLM and Agentic Apps, MITRE ATLAS, and the EU AI Act.

AgentLock has been submitted to NIST's NCCoE as a candidate implementation for their AI Agent Identity and Authorization demonstration project.

Try It

Looking for feedback on the schema design, enforcement model, and framework integrations. Issues and PRs welcome.

Top comments (0)