Skip to content
Invaris Labs

Open sourceAgentSec · AgentAuth

Security infrastructure for autonomous AI agents.

Agents read private data, invoke tools, delegate work, talk to other agents and take actions with real consequences. Application security and identity systems weren't designed for software that decides what to do at runtime.

Invaris Labs builds the infrastructure to test how agents behave, and to identify and authorize what they do.

pip install invaris-agentsec
An autonomous agent reads user prompts, retrieved documents, tool and MCP results and memory, then acts through tool calls, APIs, sub-agents and payments. AgentSec tests this workflow adversarially before production. AgentAuth gives the agent a cryptographic identity and checks scoped authority on every request.
AGENTSECAdversarial scenarios across the whole workflow, before production

Reads

  • User prompts
  • Retrieved documents
  • Tool & MCP results
  • Memory

Agent

autonomous

did:agent:QmfJZCnu…GjQmDRiMxux

Ed25519 · signs every request

Acts

  • Tools · MCP servers
  • APIs & databases
  • Sub-agents
  • Payments
AGENTAUTHIdentity and scoped, delegable authority, verified on every request

Products

Two open-source projects for agents that act with real authority.

One tests how an agent behaves under attack. The other gives it a verifiable identity and bounds what it is allowed to do.

01AgentSec

Test agents before they reach production.

AgentSec is an open-source framework for adversarial security and reliability testing. It runs stateful attack scenarios against complete agent workflows (LLMs, retrieval, memory, MCP servers, tools and sensitive actions), records the full execution trace, and checks that your security policy holds from the first step to the last.

$ agentsec test
Invaris AgentSec

42 scenarios executed
36 passed
6 findings

CRITICAL  Indirect prompt injection triggered send_email
HIGH      Retrieved confidential content appeared in the response
HIGH      Agent attempted a forbidden payment action
MEDIUM    Tool-call budget exceeded

Report written to .agentsec/report.json
Report written to .agentsec/report.html

Commands and output from the AgentSec README. Lines starting with # describe documented behaviour.

version: "1"agent:  name: support-agent  endpoint: http://localhost:8000/agentallowed_tools:  - search_documents  - create_draftforbidden_actions:  - send_email  - reveal_credentials  - execute_paymentlimits:  max_steps: 12  max_tool_calls: 10  max_cost_usd: 0.50tests:  - prompt_injection  - indirect_prompt_injection  - secret_extraction  - unauthorized_tool_use  - tool_output_poisoning  - unsafe_retrieved_documents  - loop_and_budget_limits

Policies declare what the agent may do. Tests assert behaviour, not a particular model response.

Coverage

What AgentSec tests

Every check is deterministic and opt-in by declaration. Findings are mapped to the OWASP Top 10 for Agentic Applications (opens in a new tab) (ASI01–ASI10).

Injection & poisoning

Untrusted content that tries to steer the agent.

  • Direct & indirect prompt injection

    prompt_injection · indirect_prompt_injection

    Instructions arriving from the user, or hidden in documents and tool results.

  • Tool-output & MCP-server poisoning

    tool_output_poisoning

    Adversarial content delivered through the results of the tools the agent calls.

  • Unsafe retrieved documents

    unsafe_retrieved_documents

    Retrieval pipelines that hand the agent hostile or confidential content.

  • Memory poisoning

    memory_poisoning

    Malicious instructions persisted to memory and acted on in a later session.

Authority & actions

What the agent does, and whether anyone authorised it.

  • Unauthorized tool use

    unauthorized_tool_use

    Calls to tools outside the policy's allowed set, including forbidden decoys.

  • Action without authorization

    action_without_authorization

    Effects a tool may perform globally but the current task never authorised.

  • Dangerous compositions

    dangerous_composition

    Individually allowed calls chained into exfiltration or command execution, tracked as data flow.

  • Identity & session confusion

    identity_and_session_confusion

    Acting on another user's resource or reusing a permission from another session.

  • Multi-agent privilege abuse

    multi_agent_delegation

    Sub-agents exceeding their role, confused-deputy escalation, unauthorized delegation.

Data & reliability

Leaks, runaway behaviour and drift.

  • Secret & sensitive-data leakage

    secret_extraction

    Synthetic credentials and confidential data appearing where they shouldn't.

  • Loops, budgets & cost

    loop_and_budget_limits

    Excessive steps, tool calls, tokens or cost, and missing termination.

  • Deceptive action reports

    deceptive_action_report

    Agents denying a side effect the trace shows, or claiming work that never happened.

  • Behavioural regressions

    agentsec compare

    New, fixed and worse findings across model, prompt and tool updates.

Categories that need tool_effects or agent_roles build no scenarios without them, and a multi-agent scenario run against a system that reports no agent attribution is reported as not observable, never as passed. Unauthorized financial and on-chain actions are covered by a bundled attack pack and the policy's spend_limits / address_allowlist. What a passing test does and doesn't prove (opens in a new tab).

MCP security

Scan the servers. Attack through them.

MCP servers hand agents tool descriptions and tool results, both of which can carry instructions. AgentSec tests the server definitions statically and delivers adversarial scenarios through MCP itself.

MCP testing docs (opens in a new tab)

agentsec mcp scan

Lists a server's tools, resources and prompts without calling, reading or fetching any of them, and flags:

  • Poisoned tool descriptions
  • Hidden / invisible characters
  • Tool shadowing
  • Homoglyph tool-name impersonation
  • Lying read-only / destructive annotations
  • Forbidden or unlisted tools
  • Rug pulls: pin definitions, compare across runs

agentsec test --mcp-listen

AgentSec becomes the MCP server your agent connects to, delivering the same adversarial scenarios through MCP tool results.

# agent ⇄ MCP ⇄ AgentSec

agentsec test --mcp-listen 127.0.0.1:8765

The MCP attack host has been run against a real LLM-backed agent (the Claude Code CLI, built-in tools disabled, every MCP tool simulated), with results checked into the repo.

Workflow

Built for the way you already ship.

AgentSec is CI-first. Exit codes gate the job (1 on findings, 2 on configuration errors), --seed makes runs reproducible, and reports compare across pull requests.

  1. 01

    Build agent

    agentsec init

    Declare allowed tools, forbidden actions and limits.

  2. 02

    Run AgentSec

    agentsec test

    Stateful adversarial scenarios against the full workflow.

  3. 03

    Detect failures

    .agentsec/report.html

    Input, trace, violated policy and observed action.

  4. 04

    Fix

    agentsec replay

    Re-run findings with the recorded seed to confirm the fix.

  5. 05

    Regression test

    agentsec compare

    Diff reports on every pull request; exit 1 on regressions.

  6. 06

    Ship

    uses: invarislabs/invaris-agentsec@main

    The packaged GitHub Action gates the job.

Reports
Terminal, JSON, self-contained HTML, Markdown and SARIF 2.1.0. Secrets masked in every format.
CI
Workflow annotations and job summary in GitHub Actions, a packaged Action with baseline comparison and PR comments, and SARIF to GitHub Code Scanning.
Frameworks
OpenAI-compatible HTTP (optionally streaming), LangChainAdapter for LangChain and LangGraph, and a generic CallableAdapter for in-process agents.
Extending
Python API, a pytest plugin, and attack packs, with reference packs for coding, browser, RAG, customer-support and on-chain agents.
  • Evidence over scores

    Every finding includes the input, trace, violated policy and observed action.

  • Stateful testing

    Tests cover complete workflows rather than isolated prompts.

  • Local by default

    Test locally without sending private traces to a hosted service.

  • Reproducible

    A failed scenario is replayable with the same configuration and evidence.

02AgentAuth

Give every agent an identity. Control what it can do.

AgentAuth gives each agent a self-certifying DID backed by an Ed25519 keypair. The agent proves who it is by signing every request. Capability grants say what it may do, and anyone can verify all of it without trusting the registry.

AgentAuth request flow: agent identity, signed request, scoped authority, delegation, verification.

did:agent:QmfJZCnucexGhSZqdsAcKnFcv4RxyhPFMUiGjQmDRiMxux

└─ sha2-256 multihash of the agent's signed inception event

Authorization: AgentSig did="…",kid="…#key-1",aud="api.example.com",ts="…",nonce="…",sig="…"

  1. 01

    Agent identity

    did:agent:Qm…

    A self-certifying DID derived from the agent's own Ed25519 key material and signed inception event. The registry can't mint or reassign it.

  2. 02

    Signed request

    Authorization: AgentSig …

    Every request is signed over method, path, body, audience, timestamp and a single-use nonce. No API key or bearer token crosses the wire.

  3. 03

    Scoped authority

    AgentGrant

    A short-lived capability grant: iss lets sub do scope at aud until exp. Default 15 minutes, maximum 24 hours.

  4. 04

    Delegation

    scope ⊆ parent · depth − 1

    An agent can pass a narrower slice to a sub-agent. Scopes, audiences, validity windows and limits only shrink.

  5. 05

    Verification

    root_policy

    The service checks every link, that the leaf signed the request, that the root is a principal it trusts, and that nothing is revoked.

Delegation

Authority narrows as it's delegated. It never widens.

A person issues an agent a short-lived, scoped grant. The agent can pass a narrower slice to a sub-agent, and every action traces back to the human who authorized it.

Scopes, audiences and validity windows only shrink, and depth strictly decreases. Limits on resources, spend, rate and uses can only tighten, and a hand-crafted grant that loosens one is rejected by the service.

Counters are shared across the chain. Give an agent a 50 USD budget and let it hand two sub-agents 30 USD each: together they still can't spend more than 50 USD.

  • Scopes

    tools.* covers tools.search

  • Lifetimes

    15 min default · 24 h max

  • Depth

    strictly decreases

  • Expiry

    clamped to the parent's

Delegation narrows authority. arunima grants shopper payments.* with a 5000 USD-cent budget, 2000 per call, 10 calls per 60 seconds and depth 1. shopper delegates payments.buy to helper with a 3000 budget and depth 0. A child grant with a 9000 budget would exceed its parent and is refused.
authoritynarrower →
arunima(human)──▶shopper

payments.*

  • --budget 5000
  • --per-call 2000
  • --rate 10/60
  • --depth 1
shopper(agent)──▶helper

payments.buy

  • --budget 3000
  • per-call ≤ 2000
  • rate ≤ 10/60
  • depth 0
shopper ──▶ helper--budget 9000

Refused: a child grant can't exceed its parent on any limit.

Example from the AgentAuth README. Amounts are integer USD-cents; floats are never signed.

Control

Revoke it, rotate it, switch it off, cap it.

  • Revocation that cascades

    POST /v1/revocations

    An issuer revokes one of its grants by id. Revoking a grant, or switching off any agent in the chain, cuts off everything below it.

  • Kill switch

    agentauth deactivate did:agent:… --as arunima

    An agent can be killed by itself, or by the human or org controller that countersigned its creation.

  • Rotation with pre-rotation

    agentauth rotate researcher

    The next key is committed in advance, so the current key alone can't rotate the identity. Relying parties pick up the new key automatically.

Grant limits and how they are enforced
LimitMeaning
resourcesWhat the call may touch: an exact pattern, or a prefix ending in *Enforced: Per call
spend.per_callMax amount for one callEnforced: Per call
spend.totalMax amount across all calls under this grantEnforced: Shared ledger
rateMax count calls per per seconds (sliding window)Enforced: Shared ledger
usesMax total callsEnforced: Shared ledger

Fail-closed: a resource-limited grant is refused at any endpoint that doesn't declare a resource, an unknown limit field invalidates the grant, and a mismatched spend unit is refused.

In practice

CLI, SDK and a FastAPI integration.

agentauth serve &                                            # registry :8000agentauth init arunimaagentauth init researcher --controller arunimaagentauth init summarizer --controller researcher# arunima → researcher (may delegate once) → summarizer (search only)agentauth grant arunima researcher --scope 'tools.*' --aud 127.0.0.1:9000 --depth 1 -o researcher.grantagentauth grant researcher summarizer --scope tools.search --aud 127.0.0.1:9000 \          --parent researcher.grant -o summarizer.grantagentauth inspect summarizer.grant# Revoke the root grant; the summarizer loses access tooagentauth revoke arunima <grant-id-from-inspect># Limits: a 50 USD budget (max 20 USD per call, 10 calls/min) that can be split onceagentauth grant arunima shopper --scope 'payments.*' --aud 127.0.0.1:9000 --depth 1 \          --budget 5000 --per-call 2000 --rate 10/60 -o pay.grantagentauth grant shopper helper --scope payments.buy --aud 127.0.0.1:9000 \          --budget 3000 --parent pay.grant -o helper.grant       # --budget 9000 would be refused

Snippets from the AgentAuth README.

Verification

What a service checks before it says yes.

  • Every link is signed by its issuer's current key

    No forged or stale grants

  • Each issuer is the previous link's subject

    The chain is unbroken

  • Scopes, audiences and validity only shrink; depth strictly decreases

    Delegation can't escalate

  • The leaf's subject is the agent that signed the request

    A stolen grant is useless to anyone else

  • The request signature covers the AgentGrant header

    The agent asserts which authority it's using

  • The root issuer is a principal the service trusts

    The service decides whose word counts

  • Nothing in the chain is deactivated or revoked

    Revocation and kill switches cascade

Why not API keys?

Shared secrets were built for services, not agents.

  • Shared secrets leak through logs, prompts and tool output

    Private key never leaves the agent; requests carry signatures

  • A leaked key can be replayed anywhere, forever

    Signatures are bound to method, path, body, audience (host), a timestamp and a single-use nonce

  • Identity = whatever the issuer's database says

    DID is derived from the agent's own key material; the registry can't mint or reassign it

  • Rotation means coordinating a new secret everywhere

    Rotate with one call; relying parties pick up the new key automatically

  • Stolen key = full takeover

    Pre-rotation: the next key is committed in advance, so the current key alone can't rotate the identity

  • No link between an agent and who's responsible for it

    Optional controller (a human or org DID) countersigns the agent's creation and holds a kill switch

v0.3Shipped: identity (v0.1), delegated grants (v0.2), limits (v0.3). Known gaps, like registry equivocation and the in-memory nonce cache, are documented in the threat model.

The Invaris agent security stack

Behaviour and authority, secured separately.

AgentSec determines whether an agent behaves safely. AgentAuth determines who the agent is and what it is allowed to do. Together they're the beginning of the Invaris agent security stack.

The Invaris agent security stack: AgentSec for testing, AgentAuth for identity and authorization, both around the agent.

Research & writing

Notes from building agent security in the open.

Technical writing and research notes by Arunima Chaudhuri on how agents fail, how to test for it, and what a test result actually proves.

All writing on Hashnode (opens in a new tab)

About Invaris Labs

A new execution model needs its own security infrastructure.

Traditional software follows execution paths someone wrote down. Agents interpret untrusted input, choose their own tools, retain memory and make decisions at runtime. A single poisoned document or tool response can change what they do.

Invaris Labs is building security infrastructure for that model: open, testable and verifiable without asking anyone to trust a black box.

Agents are increasingly able to
  • 01readsensitive data
  • 02invoketools
  • 03callAPIs
  • 04modifysystems
  • 05delegatework to sub-agents
  • 06messageother agents
  • 07performactions with real consequences

Founder

Arunima Chaudhuri

Arunima founded Invaris Labs and builds AgentSec and AgentAuth. She is a Research Engineer at Status, previously interned at Status, Hyperledger and Solana Labs, and holds an M.Tech in Computer Science and Engineering from NIT Warangal (2025).

  • Distributed systems
  • Peer-to-peer protocols
  • Ethereum protocol research
  • AI agent security
  • Open-source engineering

Open source

Built in the open. Read the code, break the tools.

Security infrastructure should be inspectable. Explore the code, try the tools against your own agents, open issues, contribute, and star the repositories if they're useful.

Where AgentSec welcomes contributions

Both projects are under active development. If you're building an agent and want to be an early design partner, open a discussion or get in touch.

  • Adversarial test cases
  • Agent & framework adapters
  • MCP security testing
  • Deterministic evaluators
  • Trace schemas & interoperability
  • Sandboxing & safe execution
  • Docs & vulnerable examples