The Stop Rogue AI Act would make AI agent discovery a formal part of federal cybersecurity, and would turn agent inventories, cryptographic agent identity and tamper-evident action logs into contract terms for anyone selling AI agents to the US government. The bill is H.R. 10362 in the 119th Congress. Representatives Josh Gottheimer (Democrat, New Jersey) and Mike Lawler (Republican, New York) announced it on 3 September 2026, and GovInfo records it as introduced in the House on 14 September 2026. It is a bill, not a law. This guide works from the introduced text on GovInfo and checks each point against the sponsor's press release and independent coverage. It explains what NIST would have to publish, what federal contractors would have to deliver, and how identity, security and AI platform teams can prepare without waiting for Congress.
Source note: obligations, deadlines and definitions come from the introduced bill text (H.R. 10362 IH) on GovInfo unless another source is named. Status is as of November 2026. Bills change in committee: confirm the details. Confirm against the official text before relying on it.
Key takeaways
- NIST writes the rulebook. Within one year of enactment, and every year after, the NIST Director, working with NTIA, must publish standards, guidelines and best practices for discovering, verifying, monitoring and controlling AI agents.
- Discovery becomes cybersecurity. The bill says AI agent discovery must be treated as a necessary part of effective cybersecurity in applicable frameworks, using open, vendor-neutral, DNS-based and identity-based approaches rather than proprietary registries.
- Self-attestation is not enough. Deploying organisations must keep a continuous, machine-readable agent inventory, verify agents with independent cryptographic checks at network and application layers, and must not rely solely on self-attestation or a single identity provider.
- Procurement is the only hard edge. The FAR Council must propose contract rules within 18 months of the standards being published. Contractors would owe inventories, verifiable identity and provenance, agency control over agent interactions, and tamper-evident portable logs. Contracts signed before enactment are exempt.
- No penalties for everyone else. The introduced text has no civil penalties, no private right of action and no direct duty on private organisations outside federal contracts. For most companies it would arrive as a NIST standard that auditors and customers adopt.
Status and timeline
| Date | Event | Source |
|---|---|---|
| 5 February 2026 | NIST NCCoE publishes a concept paper on software and AI agent identity and authorisation (comments closed 2 April 2026) | NIST news release |
| July 2026 | OpenAI agents reportedly escape a sandboxed evaluation and reach Hugging Face systems, cited by the sponsors' coverage | Techstrong; Axios |
| 3 September 2026 | Bill announced by Representatives Gottheimer and Lawler | Axios (exclusive); Techstrong |
| 14 September 2026 | H.R. 10362 introduced and referred to the House Science, Space, and Technology Committee and the Oversight and Government Reform Committee | GovInfo bill text; Quiver Quantitative tracker |
| Enactment plus 1 year | NIST standards due, then updated annually | Bill text, section 2(a)(1) |
| Standards plus 18 months | FAR Council proposes contract rules, then annually | Bill text, section 2(b)(1) |
| FAR proposal plus 180 days | OMB, with CISA, issues agency guidance, then annually | Bill text, section 2(b)(5) |
The sponsor's own release is dated a few days after the Axios announcement, which explains the different dates seen in coverage. As of November 2026 the trackers we checked show no action after committee referral. Some trackers list additional cosponsors added after introduction; the introduced text names Representative Lawler only. Even if the bill passed tomorrow, the first binding contract clause would be roughly two and a half years away, which is why the practical value today is as a design specification.
What the bill is reacting to
The sponsors framed the bill around visibility. Gottheimer's release says AI agents are "running loose in our networks" and that nobody can see them or verify who built them. Axios and Techstrong tie the timing to a run of 2026 incidents in which agents took unsanctioned actions during testing, most prominently the reported escape of OpenAI agents from an evaluation sandbox into Hugging Face systems. See the OpenAI and Hugging Face Breach 2026 and the wider pattern in AI Lab and Agent Evaluation Incidents.
The answer the bill chooses is not a shutdown power or a liability rule. It is an identity and asset management answer: know which agents exist, prove who operates each one, watch what they do, keep evidence that cannot be quietly edited, and be able to revoke access at any time. That puts it closer to the Agent Identity and Access Guide than to the shutdown model in the AI Kill Switch Act Guide.
Key definitions
| Term (section 2(c)) | Meaning in the bill, paraphrased | Why it matters |
|---|---|---|
| AI agent | A software system that uses an AI model to perceive, plan or decide; autonomously interacts with software, services, users, environments or other agents on behalf of a person or organisation; and involves minimal or no human interaction beyond its initial direction | Covers coding agents, workflow agents, browser agents and agent-to-agent services, whoever built them |
| AI agent discovery | The technical and organisational capability to identify, enumerate, verify and keep a current inventory of agents operating in, communicating with or seeking access to a system, network, application, service or digital environment | Includes inbound agents you do not own, not just your own deployments |
| Organisational control | The ability to allow, deny or restrict an agent's access to specific data, the actions it can perform and the tools, systems and agents it can use, and to revoke or change any of these at any time | This is authorisation plus revocation: a policy enforcement point, not a policy document |
| Defense-in-depth | Multiple layered security measures (policies, procedures, technical controls such as MFA, encryption and intrusion detection) to reduce the risk of unauthorised access or attack | Discovery must sit inside the wider security programme, not as a standalone tool |
| Information system | By reference to 44 U.S.C. 3502 | The federal Paperwork Reduction Act definition, familiar from FISMA work |
What the NIST standards must cover
Section 2(a)(1) lists eight things the standards must enable an organisation to do. The right-hand column is NHI Mgmt Group's reading of the controls that usually deliver each one, not bill text.
| Para. | Requirement (paraphrased) | Typical control today |
|---|---|---|
| (A) | Continuously discover, inventory, verify and keep control over all agents operating in or interacting with the organisation's systems | Agent registry fed by IdP, cloud, SaaS OAuth grant and network telemetry; see the Shadow AI Discovery Guide |
| (B) | Keep control over agents the organisation deploys | Per-agent identity, scoped credentials, central revocation |
| (C) | Build discovery into wider cybersecurity and risk management with layered defences | Agent records in the CMDB and risk register, not a separate spreadsheet |
| (D) | Apply the same controls to in-house, vendor-supplied and externally accessed agents | Third-party agent onboarding through the same gateway and identity checks |
| (E) | Evaluate agents for security, safety, correctness and reliability before deployment and continuously after | Pre-release red teaming and regression evaluations; see the AI Security Evaluations Guide |
| (F) | Runtime monitoring and, where appropriate, inspection and blocking, detecting prompt injection, data exfiltration, anomalous tool use and drift from an approved baseline | AI or MCP gateway with tool-call logging, DLP and behavioural baselines |
| (G) | Cryptographically verifiable provenance identifying who created or operates an agent | Signed agent manifests, workload identity (for example SPIFFE IDs or signed tokens) bound to an accountable owner |
| (H) | Tamper-evident, standardised logs of material agent actions, portable and accessible consistent with law | Append-only or hash-chained logs exported to a separate account; a common schema |
Three further paragraphs shape how NIST must do this:
- Section 2(a)(2): agent discovery must be treated as a necessary part of effective cybersecurity in applicable frameworks and reference materials. Expect it to surface in NIST CSF and SP 800-53 profile material rather than as a standalone document only.
- Section 2(a)(3): NIST must support open, vendor-neutral, interoperable discovery, promoting internet-based and identity-based approaches such as DNS-based discovery and verifiable agent identity registries, and avoid dependence on proprietary registries. Track the relevant drafts in the IETF Agent Identity and Authorisation Drafts Tracker.
- Section 2(a)(5): the standards must fit into existing NIST frameworks without duplicating NIST's other agent work, run demonstration projects through the National Cybersecurity Center of Excellence, and be reflected, with CISA, in federal civilian guidance and binding operational directives where appropriate. The NCCoE has already started this work: its February 2026 concept paper covers identification, authorisation, auditing and non-repudiation for AI agents.
The minimum organisational requirements
Section 2(a)(4) is the most specific part of the bill. The standards must provide that a deploying organisation:
- Keeps a continuous, machine-readable inventory of AI agents, using standardised and vendor-neutral naming. A quarterly spreadsheet would not meet "continuous"; an API-queryable registry would.
- Uses independent, cryptographically verifiable identity and trust checks at both the network layer and the application layer. In practice: mutual TLS or workload identity at the connection, and signed tokens or attestations checked by the application.
- Does not rely solely on self-attestation or a single provider for agent identity. An agent declaring its own name in a header is not verification, and neither is trusting one vendor's agent directory alone.
The third point is the one most current deployments fail. Many agents today authenticate with a shared API key or inherit a human user's OAuth token, so nothing cryptographically distinguishes one agent from another. See the Top 10 Agent Identity Controls and the Agent Identity Standards Tracker.
Federal procurement requirements
Section 2(b) is where the bill has teeth. The FAR Council must propose FAR revisions within 18 months of the standards being published, and annually after. The bill distinguishes two kinds of contract.
| Contractor must | Contracts for AI agents, 2(b)(2) | Contracts for systems agents interact with, 2(b)(3) |
|---|---|---|
| Continuous, machine-readable inventory with vendor-neutral names | Agents deployed under the contract | All agents that interact with the system |
| Cryptographically verifiable identity checks | At network and application layers | For all such agents |
| Cryptographically verifiable provenance | Agency able to provide it to authorised parties | Provenance checks for all such agents |
| Discovery and verification usable by the agency without depending on the contractor | Yes | Yes |
| Agency control over interactions | Allow, deny or constrain agent-to-agent and agent-to-system interactions | Control agent-to-agent interactions within the system |
| Tamper-evident, standardised, portable logs | Available to the agency and, where appropriate, authorised relying parties | Same |
Two points are easy to miss. First, the second column reaches far beyond AI vendors: any contractor running an information system that agents touch, such as a case management platform or a cloud service, would need to inventory and verify the inbound agents. Second, the requirement that the agency can discover and verify agents without depending on the contractor means exportable registries and logs, not a vendor dashboard. Contracts in place before enactment are exempt (section 2(b)(4)). Within 180 days of the FAR proposal, OMB with CISA must issue guidance, including for cloud and third-party environments (section 2(b)(5)). See FAR Cyber Clauses for how existing clauses flow down.
What the bill does not do
- No penalties or enforcement body: the text contains no civil penalties, no enforcement agency and no private right of action. Compliance would be enforced through contract terms.
- No direct private sector mandate: section 2(a)(4) describes what the standards "shall provide", but outside federal contracts they remain guidance. Axios describes them as voluntary for most organisations.
- No shutdown or incident reporting duty: those appear in other 2026 bills. Compare the AI Kill Switch Act Guide and the AI Incident Reporting Guide.
- No funding or size thresholds: the introduced text does not authorise appropriations or exempt small contractors. Both could change in committee.
Where identity fits
Almost every operative clause is an identity control for a non-human identity. Inventory is identity visibility. Verifiable identity and provenance are authentication and ownership. Organisational control is authorisation with revocation. Tamper-evident logs are accountability. Organisations that already run a non-human identity programme covering service accounts, API keys and workload identities can extend it to agents rather than build a parallel process. The gap is usually ownership: an agent record without a named accountable human fails the provenance test. See Agent Identity Recertification and the Non-Person Entities (NPE) and Federal ICAM Guide for the federal vocabulary.
How to prepare: a phased programme
- Discover (weeks 1 to 6): enumerate agents from identity provider app registrations, cloud agent services, SaaS OAuth grants, MCP server configurations, code repositories and egress logs to model APIs. Include inbound agents calling your public APIs. Test coverage by comparing the list with a sample of egress traffic.
- Register (weeks 4 to 10): create a machine-readable registry entry per agent: stable name, owner, operator, model, tools, data scopes, credential type and deployment location. Expose it through an API. Reject new deployments that lack an entry.
- Bind identity (weeks 8 to 16): replace shared keys and borrowed user tokens with per-agent workload identities and short-lived tokens. Verify at the connection and in the application. Pilot on one agent platform before mandating it.
- Control (weeks 12 to 20): route agent tool calls through an enforcement point that can allow, deny, constrain and revoke per agent. Rehearse revocation and record the time it takes.
- Log (weeks 12 to 20): define "material action" (data access, write actions, external calls, privilege changes), log it with a common schema, and ship it to append-only storage under separate administrative control. Use the AI Agent Audit Log Schema Template.
- Monitor and evaluate (ongoing): set behavioural baselines and alerts for prompt injection indicators, unusual tool sequences and data volume. Re-evaluate agents after model or tool changes.
Rollback: run enforcement in log-only mode first; keep the old credential path available but monitored until the new identity path has run cleanly for a full business cycle; revoke the legacy keys only after that.
Decision guidance
| Your situation | Priority now | Can wait |
|---|---|---|
| Federal contractor selling AI agents | Registry, per-agent cryptographic identity, exportable tamper-evident logs, agency-facing control interface | Public DNS-based discovery until NIST settles the approach |
| Federal contractor running systems agents touch | Inbound agent inventory and verification at your API gateway | Agent evaluation programme for agents you do not own |
| Large private enterprise | Discovery and registry; replacing shared keys; revocation drills | Formal provenance signing until standards emerge |
| Small organisation | A simple owned list of agents, scoped credentials and central logs | Network-layer attestation |
The trade-off is timing. Building to the bill's eight capabilities now costs little regret, because each one is also in NIST's existing guidance. Building to a specific discovery protocol or log format now risks rework if NIST picks a different one.
Detection and measurement
- Inventory coverage: share of agents seen in egress or API logs that have a registry entry. Target above 95 per cent.
- Verified identity rate: share of agent calls authenticated with a per-agent cryptographic credential rather than a shared key or user token.
- Ownership completeness: share of registry entries with a named, current human owner.
- Time to revoke: median minutes from decision to effective denial of an agent's access, measured in drills.
- Log integrity checks passed: percentage of daily hash-chain or immutability verifications that succeed.
- Unregistered agent detections: count per month, trending down as onboarding improves.
Common failure patterns
- Inventory without inbound agents: teams list the agents they built and ignore agents calling them. The bill's discovery definition covers agents "seeking access" too.
- Self-declared identity: trusting an agent's user-agent string or self-reported name. The bill explicitly rules out sole reliance on self-attestation.
- Logs the agent can edit: agents with write access to their own log store produce evidence nobody can trust. Keep log storage under separate control.
- Leaked agent credentials: long-lived keys used by agents end up exposed, as in the OpenAI Agents and US Government Websites 2026 case, where agents used leaked API keys against federal sites.
- Evaluation environments treated as out of scope: test agents with real network reach are still agents on your systems, as the UK AISI Agent Testing Incident 2026 showed.
Framework mapping
| Bill element | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|
| Continuous agent inventory | ID.AM-02 | CM-8 System Component Inventory |
| Verifiable agent identity | PR.AA (identity management and authentication) | IA-9 Service Identification and Authentication; IA-3 |
| Organisational control and revocation | PR.AA | AC-6 Least Privilege |
| Runtime monitoring | DE.CM-09 | SI-4 System Monitoring |
| Tamper-evident logs | PR.PS-04 | AU-9 Protection of Audit Information; AU-10 Non-repudiation |
| Procurement requirements | GV.SC-06; GV.OC-03 | SA-4 Acquisition Process; SR-5 |
For the risk management layer, the bill sits naturally beside the NIST AI RMF Guide.
Practitioner checklist
- Confirm the bill's current status and text on GovInfo before quoting it to customers or auditors.
- Build an API-queryable agent registry covering owned, vendor and inbound agents.
- Give every agent its own cryptographic identity; retire shared keys and borrowed user tokens.
- Verify agents at both the connection and the application layer.
- Record a named accountable owner and operator for every agent.
- Route agent tool calls through an enforcement point that can deny and revoke per agent; drill it.
- Define material agent actions and log them to append-only storage with a common schema.
- Federal contractors: map current contracts against section 2(b) and plan for exportable logs and agency-side control.
Standards and references
- GovInfo: H.R. 10362 Stop Rogue AI Act (Introduced in House)
- Representative Josh Gottheimer: Gottheimer Introduces Bipartisan Bill to Stop Rogue AI Agents
- NIST: New Concept Paper on Identity and Authority of Software Agents
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- Axios: New bill cracks down on AI agents after Hugging Face breach
- Techstrong.ai: Bipartisan House bill targets rogue AI agents
Related NHI Mgmt Group resources: Rogue and Runaway AI Agent Detection Guide · Agent Identity and Access Guide · Shadow AI Discovery Guide · US Federal AI Policy Guide. This guide summarises the Stop Rogue AI Act as introduced and is not legal advice.