Identity and revocation control plane for autonomous coding agents touching GitHub, cloud, and SaaS tools.

1. Autonomous agents are moving beyond read-only copilots and now touch code, APIs, financial tools, and customer data.
2. Enterprises need a control layer because identity, scope, attestation, delegation, and revocation are emerging as separate operational problems.
3. Security teams can no longer treat agent risk as generic AppSec because zero-day tracking is already being packaged for agent-specific vulnerabilities.
4. An open Agent Trust Protocol and verification programs indicate a standards window where a control-plane vendor can become the default implementation.

Catalyst. As the cluster shows agent-specific exploit tracking and open trust protocols emerging at the same time agents gain access to code, APIs, financial tools, and customer data, security teams suddenly need a standard way to verify and revoke non-human actors.

The product sits between the agent runtime and high-risk tools, creating a verifiable identity for every agent task before any write action is allowed. It binds each action to a delegation chain, policy scope, human owner, and revocation state, then emits an audit trail that security teams can inspect without stitching logs by hand. The system maps disclosed agent vulnerabilities to the identities, models, tools, and workflows they affect, so exposed agents can be downgraded, paused, or re-scoped automatically. Initial integrations would focus on GitHub, AWS, Okta, Jira, Slack, and internal agent orchestrators because that is where early write-capable agents create the sharpest risk.

What's different. Existing IAM, PAM, and secrets tools were built for humans, service accounts, and static workloads, not autonomous actors that delegate tasks across many tools in one workflow. Agent observability products tell teams what happened after the fact, while this product controls whether an agent should be trusted to act in the first place and can revoke that trust in real time when exploit conditions change. The defensible wedge is the combination of agent-native attestations, exploit-aware revocation, and deep integrations into the exact write surfaces where early agent deployments create risk.

Jobs to be done

flowchart LR
  Buyer[Security and platform team] --> Pain[Unverifiable agent actions and slow revocation]
  Pain --> Product[Agent attestation and delegation plane]
  Product --> Outcome[Faster agent rollout with auditable least privilege]

Executive takeaways

• The wedge is real because write-capable coding and IT agents are moving into production before enterprises have an agent-native identity, delegation, and revocation layer.
• The near-term market sits at the overlap of non-human identity security, workload identity federation, and AI agent governance; it is early but crowded enough that focus on GitHub-cloud-SaaS write paths matters.
• Buyer pain is visible in secrets sprawl, NHI overprivilege, and governance blind spots: GitGuardian, Entro, and Veza each show that machine credentials are proliferating faster than teams can inventory or rotate them.
• Incumbents already own adjacent controls, so the startup wins only if it becomes the fastest path to task-scoped attestations, delegated tokens, and exploit-aware revocation across the exact tools early agent programs use.

Market definition

Agent trust control plane software that verifies non-human actors before they take write actions, issues task-scoped delegated access across developer and admin tools, and revokes or re-scopes trust when exploit conditions or workflow context change.

Customer and buyer

Primary users are security and platform engineers running internal coding or IT agents with GitHub, cloud, ticketing, and chat access. The economic buyer is typically the CISO or VP Platform Engineering because the purchase sits between identity, AppSec, and developer-platform budgets.

Buying triggers

• A team enables asynchronous coding agents or automation bots with repository or cloud write access and immediately needs human-review, branch-protection, and token-scope guardrails around that rollout. [30][40]
• A secrets or pipeline incident exposes how static credentials on runners, bots, or MCP-style integrations can turn a small compromise into broad infrastructure access. [115][13][97]
• Identity sprawl reviews reveal that non-human identities now materially outnumber humans and that ownership, entitlement, and dormancy are poorly governed. [27][111]

Willingness to pay

Budget should exist when the control plane is framed as a prerequisite for scaling agentic development: GitHub already monetizes agent features in premium Copilot plans, while adjacent identity platforms such as Teleport and Okta sell recurring access-governance layers on top of core infrastructure. A reasonable willingness-to-pay proxy is a fraction of an existing AI coding or identity stack budget rather than a net-new standalone line item. [29][108]

Category dynamics

Growth signal 13.1% CAGR for machine identity management (2025-2033)

Validation signals

• GitHub has already shipped an asynchronous coding agent with explicit human approval, branch protections, and session logs—evidence that write-capable agent workflows are becoming mainstream enough to need controls.
• GitGuardian found 28.65 million new hardcoded secrets on public GitHub in 2025 and documented 24,008 unique secrets in MCP-related configuration files, showing how fast agent-era credential sprawl can emerge.
• Entro and Veza both show NHIs materially outnumbering humans and centralizing risky permissions, which supports the premise that unmanaged non-human access is already an enterprise-scale problem.
• Oasis and Astrix have raised large rounds around NHI and AI-era identity security, and Lyrie is explicitly pitching an Agent Trust Protocol, indicating a real if still-forming category battle.

Regulatory & technical constraints

• MCP authorization is optional and transport-dependent, so buyers will face inconsistent auth patterns across agent tools unless a broker normalizes them.
• GitHub, AWS, Azure, GCP, and Vault all center on short-lived credentials, which means the product has to be highly reliable at issuing, renewing, and revoking tokens without introducing workflow outages.
• Least privilege, prompt-injection resilience, and auditability are already core governance expectations in mainstream AI security frameworks.
• SaaS/API ecosystems expose heterogeneous token, scope, and service-account models, so breadth of integrations is a technical moat but also a delivery burden.

Competition is not a flat list. Aembit and Teleport come from workload identity and secretless access, Astrix and Oasis come from NHI discovery/governance and are moving toward agent security, and CyberArk brings incumbent machine-identity breadth. The startup only wins if it owns the cross-tool delegation graph for write-capable agents—especially GitHub, cloud IAM, Jira/Slack admin actions, and exploit-aware revocation—rather than becoming a generic NHI dashboard.

Why incumbents do not win by default

• Cloud platforms. AWS, Azure, and Google already issue short-lived workload credentials, but they stop at their own trust domains and do not unify GitHub-to-cloud-to-SaaS delegation chains or agent-specific revocation across mixed toolchains.
• Dev platforms. GitHub can secure its own coding agent with branch protections, human approval, and built-in validation, but that still leaves cross-tool identity, SaaS admin access, and post-disclosure revocation outside GitHub-native workflows.
• IAM and PAM suites. Okta and CyberArk already sell broad identity control planes, yet their economic center of gravity is workforce identity, secrets, and privileged access rather than per-task delegated authority for autonomous agents acting across many services.
• Workload identity vendors. Teleport and Aembit prove buyers will adopt short-lived workload identity, but their core value is secretless access and SPIFFE/OIDC-style federation; neither is the default exploit-intelligence and delegation-history layer for coding agents.

Enterprises are deploying write-capable coding and IT agents into GitHub, cloud IAM, Jira, Slack, and finance systems while still provisioning those agents like long-lived service accounts with no task-scoped delegation, no verifiable attestation chain, and no fast revocation path when an exploit appears. The proposed product—a purpose-built agent identity broker—sits inline between the agent runtime and high-risk write surfaces, issues short-lived per-task attestations, enforces policy-bound delegation, and triggers revocation automatically when exploit conditions or workflow context change. The beachhead is Series B–E software companies with 100–1,000 engineers that already run internal coding or IT automation agents with GitHub and cloud write access, where a security review or a vulnerability disclosure creates the immediate buying trigger. The SAM is estimated at $300M (5,000 qualifying accounts at ~$60k ACV), and the year-3 reachable market is ~$6M from 80 design-partner style customers at ~$75k ACV; no independent customer-case study was available at research time, so these estimates are bottom-up proxies that require validation through design-partner pilots.

Problem

• Autonomous coding and IT agents gain write access to GitHub, cloud consoles, Jira, Slack, and SaaS admin tools but are provisioned as shared long-lived service accounts, leaving no verifiable delegation chain.
• Security teams cannot prove which agent acted, which human approved the delegation, or what scope was in effect—making audit, compliance, and incident response manual and slow.
• When an agent-specific vulnerability is disclosed, the only containment option is a broad shutdown because there is no scoped revocation control plane.
• Existing IAM, PAM, and secrets tools were built for humans and static workloads; they do not model per-task attestations, autonomous delegation graphs, or exploit-aware revocation for agents.

Solution

• An agent identity broker that intercepts every write-capable agent action, issues a short-lived per-task attestation token binding the action to a delegation chain, policy scope, and human owner, then allows or blocks execution.
• Exploit-aware revocation: the system maps disclosed agent vulnerabilities (MCP misconfigs, leaked secrets, vulnerable runtimes) to active identities and can downgrade, pause, or re-scope affected agents automatically.
• Audit trail emitted per action without manual log stitching—SIEM-ready, covering agent identity, tool, action, outcome, and revocation state.
• Initial integrations target GitHub, AWS IAM, Okta, Jira, Slack, and common agent orchestrators; built on existing OIDC/SPIFFE/workload-federation primitives rather than a proprietary runtime.

Why we win

• Incumbents (Okta, CyberArk, Teleport, Aembit) stop at their own trust domains or broad workload identity—none deliver a unified cross-GitHub-cloud-SaaS delegation graph with exploit-aware revocation specific to coding agents.
• Posture vendors (Astrix, Oasis) provide inventory and discovery; we provide inline enforcement at the moment of write action, which is the only control that can prevent—not merely report—unauthorized agent behavior.
• The delegation graph (human owner → agent runtime → repository/job → issued token → downstream action → revocation outcome) compounds as a data moat with every integrated workflow, making displacement progressively harder.
• Standards-friendly architecture (OAuth/OIDC, SPIFFE, MCP authorization) avoids proprietary runtime lock-in and lowers buyer fear of dead-end architecture choices.
• Early design-partner focus on the GitHub-to-cloud write path creates proof-of-value (time-to-approve and time-to-revoke metrics) before incumbents can respond with equivalent agent-native depth.

Milestones

flowchart LR
  Beachhead["Series B-E coding agent teams\n(GitHub + cloud write access)"] --> Pilot["Design-partner pilot\n(GitHub-to-AWS attestation + revoke)"]
  Pilot --> Proof["Proof points\n(time-to-approve, time-to-revoke)"]
  Proof --> Expand["Integration expansion\n(Okta, Jira, Slack, GCP)"]
  Expand --> Graph["Delegation graph moat\n(cross-tool identity dataset)"]
  Graph --> Platform["Trust platform\n(finance, HR, partner agents)"]

Founding team

Experiment roadmap

Risk assessment

What must be true

• Write-capable coding and IT agents are already in production at enough Series B–E software companies in 2026 to generate active budget for inline identity controls, not just awareness.
• Security and platform engineering teams will pay for a third-party broker rather than extend existing IAM/PAM or wait for cloud-native bundling, because integration breadth and exploit-aware revocation are not on vendor roadmaps within 12–18 months.
• The delegation graph and exploit-to-identity dataset compound into a switching cost that makes displacement by a single-vendor bundle economically unattractive after 12–18 months of production use.
• Time-to-revoke can be reduced from hours/days (spreadsheet + global kill switch) to under 30 minutes per the product's inline control plane, and customers will treat this metric as an RFP-qualifying criterion.
• The startup can close 5+ paying design-partner contracts within 12 months of product launch using a direct outbound motion at pre-seed/seed scale, before requiring a scaled sales team.

Open diligence questions

• Have you spoken with 10+ platform security leads at Series B–E software companies to confirm an active budget line for agent identity controls in 2026, separate from existing IAM/PAM spend?
• In competitive evaluations, what is the win/loss record against Aembit, Oasis, and Astrix, and what is the primary decision criterion that drives each outcome?
• Do buyers prefer an inline token broker or a posture/discovery layer first, and how does that preference affect time-to-close and initial ACV?
• What is the technical depth of the GitHub-to-AWS delegation path today: is it demo-ready, pilot-ready, or production-ready, and how many engineering months separate those stages?
• Has the exploit-to-identity mapping dataset generated any customer proof of faster triage or revocation versus a baseline vault or PAM workflow?
• What is the founding team's prior experience in identity, security infrastructure, or enterprise SaaS, and how does that affect the ability to win CISO-level deals within the first year?

Model sanity

• Revenue engine. Base-case revenue is driven by reaching 20 production customers by Q4Y2 and then scaling to 80 customers at ~$75K ACV by Q4Y3.
• Must go right. The GitHub-to-AWS wedge has to convert design partners into annual contracts before the second AE and later hiring ramp fully hit the P&L.
• Model breaks if. If sales cycles drift toward 9 months or mature ACV stays closer to $65K, downside cash goes negative before the company earns a strong next-round narrative.
• Next-round proof. The next financing case is 20 production customers, a ~$1.2M ARR run-rate, and live exploit-aware revocation that proves the product is more than a pilot tool.

Scenarios

Sensitivity

flowchart LR
  Leads["Target accounts"] --> Pilots["Paid pilots"]
  Pilots --> Customers["Production customers"]
  Customers --> Expansion["More identities + integrations"]
  Customers --> Revenue["Subscription revenue"]
  Expansion --> Revenue
  Revenue --> GrossProfit["Gross profit"]
  GrossProfit --> Cash["Cash / runway"]

Flags: The jump from 20 customers at Q4Y2 to 80 at Q4Y3 requires a much more repeatable sales motion than the model has yet proven. · Gross margin improvement depends on reducing white-glove integration and onboarding work even while connector breadth expands. · Rule-of-40 is not a useful quality signal until the company grows beyond the sub-$1M annual revenue base in Y2. · Cash never goes negative in the base case only because the seed round is assumed to close at model start; any financing delay would tighten runway materially.

• Protocol fragmentation. Multiple agent frameworks and trust standards could emerge, making one control-plane interface hard to universalize. Mitigation: Support several runtimes early and anchor the product on policy enforcement and revocation outcomes rather than any single protocol.
• Incumbent expansion. Large IAM, PAM, or cloud-security vendors could extend existing products into agent identity and narrow the wedge. Mitigation: Win the earliest write-capable coding-agent workflows with faster integrations, richer delegation context, and exploit-aware controls incumbents do not yet offer.
• Market timing. Some enterprises may still be piloting agents, delaying budget until write-capable deployments become common. Mitigation: Target design partners that already have internal coding or IT agents in production and position the product as the blocker-clearing layer for security approval.