Research Report

State of AI Agent Security 2026

An evidence-aware documentation review of authorization and adjacent safety controls across 15 named open-source AI agent projects. It is not a leaderboard, benchmark, or ecosystem-wide finding.

Published · Revised · By Sanjeev Mishra · Grantex Research

15
Named open-source projects carried forward from the original article
Sources
First-party links support the project-specific observations retained here
No scores
No aggregate grade, ranking, or market-wide conclusion
Living docs
Readers should re-check current documentation before deployment

Table of Contents

  1. Methodology and disclosures
  2. Evidence boundaries
  3. Project evidence review
  4. Reported security context
  5. Interpretive OWASP mapping
  6. Authorization design questions

1. Methodology and Disclosures

This revision examines public documentation for 15 named open-source AI agent projects. Its purpose is to help readers distinguish delegated authorization from adjacent controls such as human approval, runtime identity, tracing, and activity logs. It does not assign security grades or claim that documentation alone establishes how a deployment behaves.

How the projects were selected

The projects were carried forward from the original March 2026 article because that article had already named them as examples of agent frameworks, runtimes, and application builders. The selection was editorial. It was not generated by a reproducible market inventory, random sample, popularity threshold, GitHub-star ranking, or systematic search protocol. Inclusion does not imply that a project is more important, less secure, or more representative than a project that is absent.

Publisher conflict

Grantex publishes this report and develops delegated-authorization software for AI agents. It may benefit from interest in this problem area and is not an independent testing laboratory. Grantex is therefore not included as a scored comparison entry, and this revision removes the earlier aggregate scorecard. Product claims later on this page describe Grantex's documented design and are not findings about the sampled projects.

Evidence method and limits

Authorization questions used as a reading guide

2. What This Review Can and Cannot Support

Documented oversight controls are relevant, but they are not interchangeable

First-party materials for AutoGen, LangGraph, and OpenHands describe human feedback, interruption, confirmation, or logging mechanisms. Those controls can materially improve oversight. A pause button, approval callback, trace, or event history does not by itself establish that a receiving service received and enforced a scoped, time-limited, revocable grant from a specific principal.

Missing retained evidence is not evidence that a feature is missing

For projects where this revision links only the repository, the appropriate conclusion is that this report has not retained enough stable, first-party evidence to characterize the control. It would be misleading to convert that evidence gap into a categorical “No.”

The enforcement boundary matters more than framework labels

An agent framework can expose hooks for approval, identity, policy, or telemetry while the application, gateway, identity provider, or protected service supplies the actual authorization decision. A deployment review should trace the complete path from principal approval through token or credential issuance to service-side enforcement, revocation state, and action records.

No aggregate benchmark is published

This revision does not total projects, rank frameworks, or claim that one implementation is the default or only solution. The table is an evidence index for named projects, not a comparative scorecard.

3. Project Evidence Review

The table preserves the 15-project scope of the original article and the canonical repository links. Project-specific observations appear only where a stable first-party source is linked. The absence of an observation is not an absence finding.

Project First-party material retained Evidence-safe observation
OpenClaw Canonical repository No control-specific first-party citation was retained for this revision; no absence conclusion is made.
Dify Canonical repository No control-specific first-party citation was retained for this revision; hosted and open-source controls may differ.
RAGFlow Canonical repository No control-specific first-party citation was retained for this revision; no absence conclusion is made.
AutoGen Human-in-the-loop; logging AutoGen documents user feedback and approval patterns plus runtime and event logging. These are relevant oversight and observability controls, not proof of a grant-bound authorization system.
CrewAI Canonical repository No control-specific first-party citation was retained for this revision; no absence conclusion is made.
AutoGPT Canonical repository The earlier article treated related approval and logging behavior as partial evidence, but this revision does not retain a stable first-party citation sufficient to restate that classification.
MetaGPT Canonical repository No control-specific first-party citation was retained for this revision; no absence conclusion is made.
LangGraph Interrupts and human-in-the-loop LangGraph documents pausing graph execution and resuming after external input or approval. That supports human oversight but does not alone establish scoped grant issuance or service-side enforcement.
BabyAGI Canonical repository No control-specific first-party citation was retained for this revision; no absence conclusion is made.
SuperAGI Canonical repository The earlier article treated related logging as partial evidence, but this revision does not retain a stable first-party citation sufficient to restate that classification.
AgentGPT Canonical repository No control-specific first-party citation was retained for this revision; no absence conclusion is made.
OpenHands (formerly OpenDevin) Security and action confirmation OpenHands documents confirmation policies, action-risk analysis, rejection, and security decisions in event history. These are meaningful safety controls but are not automatically equivalent to delegated authorization.
CAMEL Canonical repository No control-specific first-party citation was retained for this revision; no absence conclusion is made.
TaskWeaver Canonical repository No control-specific first-party citation was retained for this revision; no absence conclusion is made.
OpenAI Swarm Canonical repository No control-specific first-party citation was retained for this revision; no absence conclusion is made.

Evidence index revised July 12, 2026. Repository links identify the named projects; feature links support only the adjacent observations stated in their rows. No row is a security grade, certification, or finding that undocumented functionality is absent.

How to use this table

4. Reported Security Context

The third-party reports below provide context for why credential boundaries matter. They were not used to evaluate or rank the 15 projects, do not establish that a project's defaults caused an incident, and were not independently reproduced by Grantex Research.

OpenClaw deployment exposure reporting

A February 2026 Reco.ai article described publicly accessible or misconfigured OpenClaw deployments and reported credential exposure. Deployment-specific findings should not be generalized to every OpenClaw installation without examining configuration, version, and network controls.

Third-party source: Reco.ai

Moltbook database exposure reporting

Wiz reported that a Moltbook database exposure included authentication tokens and account information. Moltbook is a separate service, and this report is included only as an example of the consequences of centralized credential exposure.

Third-party source: Wiz

Public cloud API key reporting

The Hacker News reported cases in which publicly exposed Google Cloud API keys had broader access than their deployers intended. This illustrates a credential-configuration risk; it is not a finding about the projects in the review table.

Third-party source: The Hacker News

5. Interpretive OWASP Agentic Top 10 Mapping

OWASP publishes the Top 10 for Agentic Applications. The mapping below is Grantex Research's interpretation of how authorization design can relate to selected risk categories. It is not an OWASP assessment, endorsement, or finding that any sampled project violates an OWASP requirement.

OWASP Risk Description Potential authorization relevance
ASI01 Agent Goal Hijacking Broad credentials can increase the impact of a successfully hijacked agent.
ASI03 Identity & Privilege Abuse Distinct authenticated agent identities can improve attribution and least-privilege enforcement.
ASI05 Privilege & Access Escalation Scope enforcement can constrain the resources and actions available to an agent.
ASI09 Human-Agent Trust Exploitation Contextual consent and confirmation can help align sensitive actions with user intent.
ASI10 Rogue Agents Targeted revocation can shorten access after compromise or loss of trust.

6. Recommendations

Independent of any project comparison, the following questions can be used as an authorization design checklist. The appropriate implementation depends on the deployment's threat model, data sensitivity, actors, and applicable legal obligations; this report is not legal or compliance advice.

Control What it means Why it can help
Scoped grants Give agents only the resources, actions, and duration needed for a task. Limits the potential impact of credential theft, misuse, or goal hijacking.
Per-agent identity Represent each agent as a distinct authenticated subject. Supports attribution, policy enforcement, and targeted response.
Contextual user consent Ask users to approve sensitive delegated actions or permission sets when appropriate. Helps align agent activity with user intent and accountability expectations.
Granular revocation Invalidate one agent or grant without disrupting unrelated agents. Reduces the need for broad shared-credential rotation during response.
Grant-bound audit records Link important actions to an agent identity, authorization grant, and enforced scope. Supports assurance, investigation, and incident response.
Delegation controls Narrow scopes and set depth, lifetime, and revocation behavior when agents delegate. Constrains privilege propagation in multi-agent workflows.

These controls do not by themselves establish security or regulatory compliance. Deployers should also use threat modeling, secure secret storage, sandboxing, network controls, monitoring, testing, and jurisdiction-specific review.

How Grantex is designed to address these control areas

Grantex is an Apache-2.0 delegated authorization protocol for AI agents. Its specification describes signed grants with scoped claims, agent identifiers, consent workflows, targeted revocation, audit events, and bounded delegation. This is a description of the Grantex design, not a comparative benchmark result or proof that Grantex is the only implementation of these ideas. Review the current release status and known limitations before deployment.

An individual IETF Internet-Draft is publicly available. Internet-Draft publication does not imply IETF endorsement, OAuth Working Group adoption, consensus, or Internet Standard status. Project-authored control mappings and adapters are not third-party certifications or legal opinions. SDK and adapter coverage is version-specific; consult the repository's compatibility matrix for the supported surface.

View on GitHub Read the Docs Try the Playground