Claude Code on the web
Example scan · a product as its vendor documents it · read 2026-11-10 · not seen by the vendor
The same coding agent in a cloud session: a managed container with one repository attached and a proxy above it.
An example scan of a product as its vendor documents it, not of any one deployment. Disclosure: the agent that wrote this scan runs on this product, in this shape.
Built only from the vendor’s own documentation and a published, measured deployment shape. Nothing was tested. If you are the vendor and something here is wrong, the correction will be made and dated.
4 Freedom as shipped
5 Freedom at most
0 Governance it brings
1 A deployment starts
Freedom 1, governance 0: held Freedom 2, governance 0: reaches further than its governance supports; held at 1 Freedom 3, governance 0: reaches further than its governance supports; held at 1 Freedom 4, governance 0: reaches further than its governance supports; held at 1 Freedom 5, governance 0: reaches further than its governance supports; held at 1 Freedom 1, governance 1: held Freedom 2, governance 1: held Freedom 3, governance 1: reaches further than its governance supports; held at 2 Freedom 4, governance 1: reaches further than its governance supports; held at 2 Freedom 5, governance 1: reaches further than its governance supports; held at 2 Freedom 1, governance 2: held Freedom 2, governance 2: held Freedom 3, governance 2: held Freedom 4, governance 2: reaches further than its governance supports; held at 3 Freedom 5, governance 2: reaches further than its governance supports; held at 3 Freedom 1, governance 3: held Freedom 2, governance 3: held Freedom 3, governance 3: held Freedom 4, governance 3: held Freedom 5, governance 3: reaches further than its governance supports; held at 4 Freedom 1, governance 4: held Freedom 2, governance 4: held Freedom 3, governance 4: held Freedom 4, governance 4: held Freedom 5, governance 4: held 0 Unstated 1 Stated 2 Owned 3 Bounded 4 Proven 1 Answers 2 Suggests 3 Acts 4 Acts widely 5 Coordinates Freedom: what the agent does on its own → Governance: how it is controlled → Claude Code on the web, with its optional controls and modes turned on Claude Code (web) How to read it
This is a product, not a deployment. A product has no owner, no policy and no mandate until somebody runs it, so most of the governance ladder is the operator's to climb. What this page shows is the starting point: what the product does and controls as shipped , and what it can do and control when its options are turned on.
As shipped it reaches freedom level 4 (Acts widely); with its other modes and connections it can reach 5. The governance it brings by itself is level 0 (Unstated). 15 indicators hold as shipped and 2 more are available.
An indicator with no evidence is reported as not evidenced; it is never read as a no.
The grant: what it can actually do
The questions above the line measure what is said about an agent: its purpose, its rules, its controls. The grant is the other half: what its permissions let it do, capability by capability, and what stands in the way of each. This is RiskMandate's measurement, and it depends on the permissions a deployment was given.
project read.file.project none · observed Read the project it is working on write.file.project none · observed Change the project it is working on write.repository.project none · observed Commit to the repository it was pointed at self execute.process.self not in the grant Run programs inside its own sandbox only grant.credential.self not in the grant Change its own permission settings host read.file.host none · observed Read any file the account can reach write.file.host none · observed Change any file the account can reach delete.file.host none · observed Delete files anywhere the account can reach execute.process.host none · observed Run programs as the account read.credential.host none · observed Read credentials stored where it runs create.schedule.host boundary · observed Create something that outlives the turn where it runs (a cron, a service) read.record.history none · observed Read a retained record: shell history, past sessions read.record.browsing not in the grant Read every page you visit tenant send.endpoint.allowed boundary · observed Reach a permitted list of hosts authenticate-as.credential.tenant boundary · inferred Act in accounts with the credentials it holds read.message.tenant not in the grant Read mail or chat it is connected to write.repository.tenant setting · observed Push to a code host (any branch it can reach) authenticate-as.credential.signing none · observed Sign commits with the key it holds write.budget.tenant not in the grant Spend money or tokens against an account it holds create.schedule.tenant setting · self-reported Create something that outlives the session, on the platform (a routine, a scheduled trigger, a new session) world send.endpoint.world not in the grant Reach any host on the internet send.message.world not in the grant Send a message to anyone create.record.world not in the grant Publish packages, images or pages under the name it holds nothing in the way a rule in prose a setting it could change a boundary outside its reach The grant 15 of the 23 capabilities Behind a boundary (the only barrier that is a control) 3 With nothing, a rule in prose or a setting in the way 12 Rows observed or measured on the thing itself 13 of 15 The mandate none: a product has no mandate until an operator writes one, so there is no delta to compute here
Source: anthropic/claude-code-remote/ccr-container , profile version 2026-09-05.2. Its publisher states: "This describes a published deployment shape. It is not an assessment, an audit, a certification or a security review of any named product, and it carries no adjective and no score." The counts above are that profile's rows, counted; the levels on this page are GAMMA-Ray's and come from the questions.
Capability Barrier How it is known authenticate-as.credential.signingnone observed delete.file.hostnone observed read.credential.hostnone observed read.file.hostnone observed read.record.historynone observed authenticate-as.credential.tenantboundary inferred send.endpoint.allowedboundary observed execute.process.hostnone observed write.file.hostnone observed write.file.projectnone observed write.repository.projectnone observed write.repository.tenantsetting observed read.file.projectnone observed create.schedule.tenantsetting self-reported create.schedule.hostboundary observed
The work order
Governance level 1 needs evidence of:
a policy or written rules (I34 A governance policy for agents is published; or I47 A limit on it is a rule in prose) For a product, some of this is the operator's to supply: nobody can ship an owner or a policy in a box.
What its evidence reaches
21 questions 69 indicators 279 provisions, by instrument Salesforce 31 of 34 linked EAAMM 12 of 12 linked OWASP 34 of 35 linked MCP authorization 15 of 15 linked AAGMM 12 of 12 linked Microsoft 45 of 88 linked NIST AI RMF 50 of 72 linked EU AI Act 10 of 11 linked Salesforce, Level 0: Fixed Rules and Repetitive Tasks (Chatbots and Co-pilots): Automation of repetitive tasks using predefined rules, with no reasoning or learning capabilities. At this level, chatbots and co-pilots ar… Salesforce, Level 0, how companies can advance from Level 0 to Level 1: Identify use cases where chatbots and co-pilots are limited by rigid decision trees, and explore opportunities for reasoning capabilities t… Salesforce, Level 0, how companies can advance from Level 0 to Level 1: Conduct time studies to quantify capacity saved by having agents automate tasks and recommend actions. Salesforce, Level 0, how companies can advance from Level 0 to Level 1: Select use cases aligned with the organization’s risk tolerance and establish a mitigation strategy (e.g., Employee-facing Agent vs. Custom… Salesforce, Level 0, how companies can advance from Level 0 to Level 1: Ensure data quality and availability by starting with a harmonized data source (e.g., one CRM Org) and plan for a broader data strategy as… Salesforce, Level 0, how companies can advance from Level 0 to Level 1: Focus not only on time savings but also on value and personalized customer experiences. Salesforce, Level 0, how companies can advance from Level 0 to Level 1: Quantify time savings and demonstrate early efficiency metrics, such as reduced response times and cost savings from automation. Salesforce, Level 1: Information Retrieval Agents: Agents that assist humans by retrieving information and recommending actions. Salesforce, Level 1, how to advance from Level 1 to Level 2: Shift from recommendations to actions, allowing agents to autonomously execute tasks, reducing manual error and speeding up completion. Salesforce, Level 1, how to advance from Level 1 to Level 2: Harmonize additional data, ensuring it is cleansed, transformed, and pre-processed as new sources are integrated. Salesforce, Level 1, how to advance from Level 1 to Level 2: Establish a broader governance framework with testing methods, performance metrics, and continuous monitoring. Salesforce, Level 1, how to advance from Level 1 to Level 2: Consider how user feedback will be gathered and incorporated. Salesforce, Level 1, how to advance from Level 1 to Level 2: For customer-facing agents, ensure brand consistency is reflected. Salesforce, Level 1, how to advance from Level 1 to Level 2: Measure ROI based on efficiency and effectiveness metrics like time savings, case deflection rates, and customer satisfaction. Salesforce, Level 2: Simple Orchestration, Single Domain: Agents that autonomously orchestrate low complexity tasks in a siloed data environment. Salesforce, Level 2, how to advance from Level 2 to Level 3: Decide whether to build one multi-functional agent or multiple agents working together to achieve common goals. Consider latency impacts wh… Salesforce, Level 2, how to advance from Level 2 to Level 3: Grant agents access similar to human workers, ensuring separation of duties and applying the principle of least privilege. Salesforce, Level 2, how to advance from Level 2 to Level 3: Design architecture to support future complexity, incorporating standards and protocols to avoid constant re-architecture. Salesforce, Level 2, how to advance from Level 2 to Level 3: Use out-of-the-box API connectors to extend agents’ capabilities beyond single domains. Salesforce, Level 3: Complex Orchestration, Multiple Domain: Agents that autonomously orchestrate multiple workflows with harmonized data across multiple domains. Salesforce, Level 3, how to advance from Level 3 to Level 4: Focus on use cases that require real-time, cross-domain agent collaboration, optimizing complex workflows with dynamic agent teams. Salesforce, Level 3, how to advance from Level 3 to Level 4: Develop a universal agent communication layer (APIs, “agent bus”) for seamless collaboration. Salesforce, Level 3, how to advance from Level 3 to Level 4: Implement dynamic agent discovery (registration, de-registration, and de-duplication) for ongoing maintenance. Salesforce, Level 3, how to advance from Level 3 to Level 4: Design a scalable architecture that supports any-to-any agent interactions. Salesforce, Level 3, how to advance from Level 3 to Level 4: Establish fine-grained access control, security policies, and a robust governance framework covering auditability, error handling, and tran… Salesforce, Level 3, how to advance from Level 3 to Level 4: Create layered human/AI supervision based on a risk framework. Salesforce, Level 3, how to advance from Level 3 to Level 4: Develop a sustainable AI Agent Lifecycle Management methodology. Salesforce, Level 3, how to advance from Level 3 to Level 4: Measure ROI by assessing efficiency, effectiveness, experience, and risk mitigation. Salesforce, Level 4: Multi-Agent Orchestration: Any-to-any-agent operability across disparate stacks with agent supervision. Salesforce, Level 4, how to maximize value: Evolve security and governance for ecosystem-wide collaboration Salesforce, Level 4, how to maximize value: Explore new business models enabled by agent collaboration Salesforce, Level 4, how to maximize value: Develop metrics to quantify multi-agent system value Salesforce, Level 4, how to maximize value: Create feedback mechanisms to improve agent interactions Salesforce, Level 4, how to maximize value: Measure ROI by tracking overall business impact from multi-agent collaboration (e.g., revenue growth, cost savings, customer retention) EAAMM, L1 Assistive (survey item Q9): AI responds to explicit prompts; human operates and controls all actions. EAAMM, L2 Collaborative (survey item Q9): AI suggests actions and drafts; human reviews and approves. EAAMM, L3 Consultative (survey item Q9): AI handles routine tasks autonomously; human consulted on exceptions. EAAMM, L4 Supervisory (survey item Q9): AI operates independently on complex tasks; human approves critical decisions. EAAMM, L5 Autonomous (survey item Q9): AI operates with full autonomy within defined boundaries; human monitors. EAAMM, Readiness dimension 1: governance infrastructure EAAMM, Readiness dimension 2: data architecture EAAMM, Readiness dimension 3: workforce adaptation EAAMM, Readiness dimension 4: risk management EAAMM, Prerequisite, L2 to L3: established data quality protocols EAAMM, Prerequisite, L2 to L3: formal escalation procedures EAAMM, Prerequisite, L2 to L3: demonstrated reliability metrics on routine tasks OWASP, AT0 Shadow AI: No organisational awareness or approval. Users self-adopting AI tools outside governance. OWASP, AT1 Vendor Embedded Assistant: Fully vendor-controlled. You consume it, not build it. OWASP, AT2 Platform Integrated: AI-native platform with your data. Cannot execute arbitrary code. OWASP, AT3 Citizen Developer Agent: Low-code/no-code platform. User configures flows and prompts, not code. Actions on real org data. OWASP, AT4 Code Executing Agent: Generates and executes code with local/cloud privileges. OWASP, AT5 Custom In-House Agent: You built it. You control identity, tools, and boundaries. OWASP, AT6 Externally Extended Agent: Connects to external tools/services across trust boundaries. OWASP, AT7 Multi-Agent Orchestration: Multiple agents coordinate within your organization. OWASP, AT8 Federated / Cross Boundary: Agents operate across organizational boundaries. OWASP, Maturity Level 0 Unaware and Ad Hoc, key enterprise action: Identify/document shadow agentic AI deployments OWASP, Maturity Level 0 Unaware and Ad Hoc, key enterprise action: Establish executive awareness and interim ownership OWASP, Maturity Level 0 Unaware and Ad Hoc, key enterprise action: Introduce baseline logging/data handling OWASP, Maturity Level 0 Unaware and Ad Hoc, key enterprise action: Issue temporary usage guidelines OWASP, Maturity Level 0 Unaware and Ad Hoc, key enterprise action: Initiate preliminary risk assessments OWASP, Maturity Level 1 Experimentation without Guardrails, key enterprise action: Formalize pilot approval/review processes OWASP, Maturity Level 1 Experimentation without Guardrails, key enterprise action: Define initial autonomy limits/tool controls OWASP, Maturity Level 1 Experimentation without Guardrails, key enterprise action: Create centralized agentic systems registry OWASP, Maturity Level 1 Experimentation without Guardrails, key enterprise action: Standardize audit logging/version control OWASP, Maturity Level 1 Experimentation without Guardrails, key enterprise action: Establish regular governance reporting OWASP, Maturity Level 2 Policy-Defined, Human-in-the-Loop, key enterprise action: Publish formal agentic AI governance policies OWASP, Maturity Level 2 Policy-Defined, Human-in-the-Loop, key enterprise action: Implement human-in-the-loop workflows OWASP, Maturity Level 2 Policy-Defined, Human-in-the-Loop, key enterprise action: Designate accountable executives/governance bodies OWASP, Maturity Level 2 Policy-Defined, Human-in-the-Loop, key enterprise action: Deploy AI-SBOM/provenance systems OWASP, Maturity Level 2 Policy-Defined, Human-in-the-Loop, key enterprise action: Establish structured incident/audit processes OWASP, Maturity Level 2 Policy-Defined, Human-in-the-Loop, key enterprise action: Add owners for agents in registry and define transfer protocol OWASP, Maturity Level 3 Integrated, Continuous Oversight, key enterprise action: Deploy real-time monitoring/anomaly detection OWASP, Maturity Level 3 Integrated, Continuous Oversight, key enterprise action: Implement kill switches/autonomy controls OWASP, Maturity Level 3 Integrated, Continuous Oversight, key enterprise action: Enforce governance via machine-readable policies OWASP, Maturity Level 3 Integrated, Continuous Oversight, key enterprise action: Integrate telemetry into observability platforms OWASP, Maturity Level 3 Integrated, Continuous Oversight, key enterprise action: Establish dedicated AI Security Operations OWASP, Maturity Level 4 Adaptive, Self-Regulating Governance, key enterprise action: Implement self-adjusting policy/risk engines OWASP, Maturity Level 4 Adaptive, Self-Regulating Governance, key enterprise action: Deploy cryptographic agent identity/trust OWASP, Maturity Level 4 Adaptive, Self-Regulating Governance, key enterprise action: Operate regulator-ready compliance dashboards OWASP, Maturity Level 4 Adaptive, Self-Regulating Governance, key enterprise action: Automate audit evidence/certification OWASP, Maturity Level 4 Adaptive, Self-Regulating Governance, key enterprise action: Institutionalize cross-jurisdictional alignment MCP authorization, Authorization (draft): MCP servers MUST implement OAuth 2.0 Protected Resource Metadata (RFC 9728). MCP authorization, Authorization (draft): MCP authorization servers MUST provide at least one discovery mechanism: OAuth 2.0 Authorization Server Metadata (RFC 8414) or OpenID Conne… MCP authorization, Authorization (draft): Authorization servers MUST implement OAuth 2.1 with appropriate security measures for both confidential and public clients. MCP authorization, Authorization (draft): Authorization servers and MCP clients SHOULD support OAuth Client ID Metadata Documents. MCP authorization, Authorization (draft): MCP servers SHOULD include a scope parameter in the WWW-Authenticate header to indicate the scopes required for accessing the resource. MCP authorization, Authorization (draft): MCP clients SHOULD follow the principle of least privilege by requesting only the scopes necessary for their intended operations. MCP authorization, Authorization (draft): MCP authorization servers SHOULD include the iss parameter in authorization responses (RFC 9207), advertised in their metadata. MCP authorization, Authorization (draft): MCP clients MUST implement Resource Indicators for OAuth 2.0 (RFC 8707). MCP authorization, Authorization (draft): Authorization MUST be included in every HTTP request from client to server. MCP authorization, Authorization (draft): Access tokens MUST NOT be included in the URI query string. MCP authorization, Authorization (draft): MCP servers MUST validate that access tokens were issued specifically for them as the intended audience. MCP authorization, Authorization (draft): MCP servers MUST NOT accept or transit any other tokens. MCP authorization, Authorization (draft): Invalid or expired tokens MUST receive a HTTP 401 response. MCP authorization, Authorization (draft): MCP Servers SHOULD NOT include offline_access in WWW-Authenticate scope or Protected Resource Metadata scopes_supported. MCP authorization, Authorization (draft): Servers MUST account for scope hierarchies, where a broader scope implies narrower ones, when deciding whether a token is sufficient for an… AAGMM, GD-01: Agent Lifecycle Management AAGMM, GD-02: Identity & Access Control AAGMM, GD-03: Observability AAGMM, GD-04: Policy Enforcement AAGMM, GD-05: Data Governance AAGMM, GD-06: Human Oversight AAGMM, GD-07: Sprawl Containment AAGMM, GD-08: Audit & Compliance AAGMM, GD-09: Inter-Agent Coordination AAGMM, GD-10: Risk Classification AAGMM, GD-11: Incident Response AAGMM, GD-12: Continuous Improvement Microsoft, 100: Initial, AI strategy and experience: No AI agent strategy or vision, no executive sponsor Microsoft, 100: Initial, AI strategy and experience: Pilots are sporadic or tactical Microsoft, 100: Initial, AI strategy and experience: Limited AI or business alignment Microsoft, 100: Initial, AI strategy and experience: No Responsible AI (RAI) awareness Microsoft, 100: Initial, Business strategy: Human-only workflows Microsoft, 100: Initial, Business strategy: Work is manually intensive Microsoft, 100: Initial, Business strategy: No processes designed for automation, orchestration, or agent collaboration Microsoft, 100: Initial, AI governance and security: No governance Microsoft, 100: Initial, AI governance and security: Basic information compliance and security Microsoft, 100: Initial, AI governance and security: No operational model Microsoft, 100: Initial, AI governance and security: No support model Microsoft, 100: Initial, Technology and data: Fragmented tooling Microsoft, 100: Initial, Technology and data: No technical architecture or reference architectures Microsoft, 100: Initial, Technology and data: Limited infrastructure (outstation agents for adoption at scale) Microsoft, 100: Initial, Organization and culture: No training or enablement, isolated pilots/training Microsoft, 100: Initial, Organization and culture: No champions or communities Microsoft, 100: Initial, Organization and culture: Unclear business value for adoption at scale Microsoft, 200: Repeatable, AI strategy and experience: Early vision forming Microsoft, 200: Repeatable, AI strategy and experience: Limited leadership alignment Microsoft, 200: Repeatable, AI strategy and experience: Informal strategy Microsoft, 200: Repeatable, Business strategy: Pilots improve single workflow steps Microsoft, 200: Repeatable, Business strategy: Incremental improvements Microsoft, 200: Repeatable, Business strategy: No end-to-end process redesign Microsoft, 200: Repeatable, Business strategy: Early value story forming; Microsoft, 200: Repeatable, Business strategy: measurement Microsoft, 200: Repeatable, AI governance and security: Early policies Microsoft, 200: Repeatable, AI governance and security: Separate development, test, production environments exist for security reviews Microsoft, 200: Repeatable, AI governance and security: Basic environment separation Microsoft, 200: Repeatable, AI governance and security: Basic monitoring and maintenance of AI Microsoft, 200: Repeatable, Technology and data: Basic environment structure Microsoft, 200: Repeatable, Technology and data: Partial reuse of some connectors Microsoft, 200: Repeatable, Technology and data: Limited awareness across early adopters Microsoft, 200: Repeatable, Organization and culture: Sporadic training, informal communities Microsoft, 200: Repeatable, Organization and culture: Unclear roles and adoption ownership Microsoft, 200: Repeatable, Organization and culture: Limited awareness across early adopters Microsoft, 300: Defined, AI strategy and experience: Formal AI/agent strategy Microsoft, 300: Defined, AI strategy and experience: Cross-functional planning and goals Microsoft, 300: Defined, AI strategy and experience: Executive sponsor Microsoft, 300: Defined, AI strategy and experience: KPIs/PIs tracked, regular reporting Microsoft, 300: Defined, Business strategy: Documented governance model Microsoft, 300: Defined, Business strategy: Primary business metrics Microsoft, 300: Defined, Business strategy: Human-agent teaming defined for priority business processes Microsoft, 300: Defined, Business strategy: KPI guidelines defined; real-risk documented and mitigated Microsoft, 300: Defined, AI governance and security: Standardized architecture Microsoft, 300: Defined, AI governance and security: AI practices Microsoft, 300: Defined, AI governance and security: Reusable components Microsoft, 300: Defined, AI governance and security: Telemetry and data readiness platforms ensure platform use Microsoft, 300: Defined, Technology and data: Formal enablement Microsoft, 300: Defined, Technology and data: Active makers/communities Microsoft, 300: Defined, Technology and data: Defined enablement models and systems Microsoft, 300: Defined, Technology and data: Contextual knowledge base with enablement assets Microsoft, 300: Defined, Organization and culture: Formal onboarding, active maker/community motions Microsoft, 300: Defined, Organization and culture: Regular knowledge sharing and enablement assets Microsoft, 400: Capable, AI strategy and experience: AI integrated in enterprise planning Microsoft, 400: Capable, AI strategy and experience: Cross-department alignment Microsoft, 400: Capable, AI strategy and experience: Strategic measurement Microsoft, 400: Capable, AI strategy and experience: RAI guiding design Microsoft, 400: Capable, Business strategy: Cross-system orchestration Microsoft, 400: Capable, Business strategy: Domain redesign post agent optimization Microsoft, 400: Capable, Business strategy: Measurable business value agent and optimization loops Microsoft, 400: Capable, Business strategy: Strong transformation assessment Microsoft, 400: Capable, AI governance and security: Proactive governance with automation monitoring and alerts Microsoft, 400: Capable, AI governance and security: Continuous improvement loop Microsoft, 400: Capable, AI governance and security: RAI embedded into lifecycle gates Microsoft, 400: Capable, Technology and data: Scalable enterprise foundations Microsoft, 400: Capable, Technology and data: Automated deployment and quality assurance guidance Microsoft, 400: Capable, Technology and data: Shared data management and optimization Microsoft, 400: Capable, Technology and data: Performance tuning Microsoft, 400: Capable, Organization and culture: Champions embedded in organization Microsoft, 400: Capable, Organization and culture: Shared acceleration models Microsoft, 400: Capable, Organization and culture: Shared center engagement and incentives Microsoft, 400: Capable, Organization and culture: Culture of optimization Microsoft, 500: Efficient, AI strategy and experience: AI-first culture Microsoft, 500: Efficient, AI strategy and experience: Continuous strategic iteration Microsoft, 500: Efficient, AI strategy and experience: Exec-level accountability Microsoft, 500: Efficient, Business strategy: Adaptive, autonomous processes Microsoft, 500: Efficient, Business strategy: Continuous optimization Microsoft, 500: Efficient, Business strategy: AI-enabled new innovations and investment Microsoft, 500: Efficient, Business strategy: RAI is part of enterprise culture Microsoft, 500: Efficient, AI governance and security: Predictive risk management Microsoft, 500: Efficient, AI governance and security: Real-time compliance monitoring and controls Microsoft, 500: Efficient, AI governance and security: Automated remediation, always-on improvement loop Microsoft, 500: Efficient, Technology and data: Advanced multi-agent patterns Microsoft, 500: Efficient, Technology and data: Self-improving community Microsoft, 500: Efficient, Technology and data: Emerging innovation agents Microsoft, 500: Efficient, Technology and data: Predictive agents used to guide reliability and performance Microsoft, 500: Efficient, Organization and culture: Self-sustaining community, emerging innovation agents Microsoft, 500: Efficient, Organization and culture: Continuous learning culture with clear incentives NIST AI RMF, GOVERN 1.1: Legal and regulatory requirements involving AI are understood, managed, and documented. NIST AI RMF, GOVERN 1.2: The characteristics of trustworthy AI are integrated into organizational policies, processes, and procedures. NIST AI RMF, GOVERN 1.3: Processes and procedures are in place to determine the needed level of risk management activities based on the organization's risk toleranc… NIST AI RMF, GOVERN 1.4: The risk management process and its outcomes are established through transparent policies, procedures, and other controls based on organiza… NIST AI RMF, GOVERN 1.5: Ongoing monitoring and periodic review of the risk management process and its outcomes are planned, organizational roles and responsibiliti… NIST AI RMF, GOVERN 1.6: Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities. NIST AI RMF, GOVERN 1.7: Processes and procedures are in place for decommissioning and phasing out of AI systems safely and in a manner that does not increase risks… NIST AI RMF, GOVERN 2.1: Roles and responsibilities and lines of communication related to mapping, measuring, and managing AI risks are documented and are clear to… NIST AI RMF, GOVERN 2.2: The organization’s personnel and partners receive AI risk management training to enable them to perform their duties and responsibilities c… NIST AI RMF, GOVERN 2.3: Executive leadership of the organization takes responsibility for decisions about risks associated with AI system development and deploymen… NIST AI RMF, GOVERN 3.1: Decision-makings related to mapping, measuring, and managing AI risks throughout the lifecycle is informed by a diverse team (e.g., diversi… NIST AI RMF, GOVERN 3.2: Policies and procedures are in place to define and differentiate roles and responsibilities for human-AI configurations and oversight of AI… NIST AI RMF, GOVERN 4.1: Organizational policies, and practices are in place to foster a critical thinking and safety-first mindset in the design, development, depl… NIST AI RMF, GOVERN 4.2: Organizational teams document the risks and potential impacts of the AI technology they design, develop, deploy, evaluate and use, and comm… NIST AI RMF, GOVERN 4.3: Organizational practices are in place to enable AI testing, identification of incidents, and information sharing. NIST AI RMF, GOVERN 5.1: Organizational policies and practices are in place to collect, consider, prioritize, and integrate feedback from those external to the team… NIST AI RMF, GOVERN 5.2: Mechanisms are established to enable AI actors to regularly incorporate adjudicated feedback from relevant AI actors into system design and… NIST AI RMF, GOVERN 6.1: Policies and procedures are in place that address AI risks associated with third-party entities, including risks of infringement of a third… NIST AI RMF, GOVERN 6.2: Contingency processes are in place to handle failures or incidents in third-party data or AI systems deemed to be high-risk. NIST AI RMF, MANAGE 1.1: A determination is made as to whether the AI system achieves its intended purpose and stated objectives and whether its development or depl… NIST AI RMF, MANAGE 1.2: Treatment of documented AI risks is prioritized based on impact, likelihood, or available resources or methods. NIST AI RMF, MANAGE 1.3: Responses to the AI risks deemed high priority as identified by the Map function, are developed, planned, and documented. Risk response opt… NIST AI RMF, MANAGE 1.4: Negative residual risks (defined as the sum of all unmitigated risks) to both downstream acquirers of AI systems and end users are document… NIST AI RMF, MANAGE 2.1: Resources required to manage AI risks are taken into account, along with viable non-AI alternative systems, approaches, or methods – to red… NIST AI RMF, MANAGE 2.2: Mechanisms are in place and applied to sustain the value of deployed AI systems. NIST AI RMF, MANAGE 2.3: Procedures are followed to respond to and recover from a previously unknown risk when it is identified. NIST AI RMF, MANAGE 2.4: Mechanisms are in place and applied, responsibilities are assigned and understood to supersede, disengage, or deactivate AI systems that de… NIST AI RMF, MANAGE 3.1: AI risks and benefits from third-party resources are regularly monitored, and risk controls are applied and documented. NIST AI RMF, MANAGE 3.2: Pre-trained models which are used for development are monitored as part of AI system regular monitoring and maintenance. NIST AI RMF, MANAGE 4.1: Post-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other re… NIST AI RMF, MANAGE 4.2: Measurable activities for continual improvements are integrated into AI system updates and include regular engagement with interested parti… NIST AI RMF, MANAGE 4.3: Incidents and errors are communicated to relevant AI actors including affected communities. Processes for tracking, responding to, and reco… NIST AI RMF, MAP 1.1: Intended purpose, potentially beneficial uses, context-specific laws, norms and expectations, and prospective settings in which the AI syst… NIST AI RMF, MAP 1.2: Inter-disciplinary AI actors, competencies, skills and capacities for establishing context reflect demographic diversity and broad domain a… NIST AI RMF, MAP 1.3: The organization’s mission and relevant goals for the AI technology are understood and documented. NIST AI RMF, MAP 1.4: The business value or context of business use has been clearly defined or – in the case of assessing existing AI systems – re-evaluated. NIST AI RMF, MAP 1.5: Organizational risk tolerances are determined and documented. NIST AI RMF, MAP 1.6: System requirements (e.g., “the system shall respect the privacy of its users”) are elicited from and understood by relevant AI actors. De… NIST AI RMF, MAP 2.1: The specific task, and methods used to implement the task, that the AI system will support is defined (e.g., classifiers, generative models… NIST AI RMF, MAP 2.2: Information about the AI system’s knowledge limits and how system output may be utilized and overseen by humans is documented. Documentatio… NIST AI RMF, MAP 2.3: Scientific integrity and TEVV considerations are identified and documented, including those related to experimental design, data collection… NIST AI RMF, MAP 3.1: Potential benefits of intended AI system functionality and performance are examined and documented. NIST AI RMF, MAP 3.2: Potential costs, including non-monetary costs, which result from expected or realized AI errors or system functionality and trustworthiness… NIST AI RMF, MAP 3.3: Targeted application scope is specified and documented based on the system’s capability, established context, and AI system categorization. NIST AI RMF, MAP 3.4: Processes for operator and practitioner proficiency with AI system performance and trustworthiness – and relevant technical standards and c… NIST AI RMF, MAP 3.5: Processes for human oversight are defined, assessed, and documented in accordance with organizational policies from GOVERN function. NIST AI RMF, MAP 4.1: Approaches for mapping AI technology and legal risks of its components – including the use of third-party data or software – are in place,… NIST AI RMF, MAP 4.2: Internal risk controls for components of the AI system including third-party AI technologies are identified and documented. NIST AI RMF, MAP 5.1: Likelihood and magnitude of each identified impact (both potentially beneficial and harmful) based on expected use, past uses of AI systems… NIST AI RMF, MAP 5.2: Practices and personnel for supporting regular engagement with relevant AI actors and integrating feedback about positive, negative, and un… NIST AI RMF, MEASURE 1.1: Approaches and metrics for measurement of AI risks enumerated during the Map function are selected for implementation starting with the mos… NIST AI RMF, MEASURE 1.2: Appropriateness of AI metrics and effectiveness of existing controls is regularly assessed and updated including reports of errors and impa… NIST AI RMF, MEASURE 1.3: Internal experts who did not serve as front-line developers for the system and/or independent assessors are involved in regular assessments… NIST AI RMF, MEASURE 2.1: Test sets, metrics, and details about the tools used during test, evaluation, validation, and verification (TEVV) are documented. NIST AI RMF, MEASURE 2.2: Evaluations involving human subjects meet applicable requirements (including human subject protection) and are representative of the releva… NIST AI RMF, MEASURE 2.3: AI system performance or assurance criteria are measured qualitatively or quantitatively and demonstrated for conditions similar to deploym… NIST AI RMF, MEASURE 2.4: The functionality and behavior of the AI system and its components – as identified in the MAP function – are monitored when in production. NIST AI RMF, MEASURE 2.5: The AI system to be deployed is demonstrated to be valid and reliable. Limitations of the generalizability beyond the conditions under whic… NIST AI RMF, MEASURE 2.6: AI system is evaluated regularly for safety risks – as identified in the MAP function. The AI system to be deployed is demonstrated to be s… NIST AI RMF, MEASURE 2.7: AI system security and resilience – as identified in the MAP function – are evaluated and documented. NIST AI RMF, MEASURE 2.8: Risks associated with transparency and accountability – as identified in the MAP function – are examined and documented. NIST AI RMF, MEASURE 2.9: The AI model is explained, validated, and documented, and AI system output is interpreted within its context – as identified in the MAP fu… NIST AI RMF, MEASURE 2.10: Privacy risk of the AI system – as identified in the MAP function – is examined and documented. NIST AI RMF, MEASURE 2.11: Fairness and bias – as identified in the MAP function – are evaluated and results are documented. NIST AI RMF, MEASURE 2.12: Environmental impact and sustainability of AI model training and management activities – as identified in the MAP function – are assessed a… NIST AI RMF, MEASURE 2.13: Effectiveness of the employed TEVV metrics and processes in the MEASURE function are evaluated and documented. NIST AI RMF, MEASURE 3.1: Approaches, personnel, and documentation are in place to regularly identify and track existing, unanticipated, and emergent AI risks based… NIST AI RMF, MEASURE 3.2: Risk tracking approaches are considered for settings where AI risks are difficult to assess using currently available measurement technique… NIST AI RMF, MEASURE 3.3: Feedback processes for end users and impacted communities to report problems and appeal system outcomes are established and integrated into… NIST AI RMF, MEASURE 4.1: Measurement approaches for identifying AI risks are connected to deployment context(s) and informed through consultation with domain expert… NIST AI RMF, MEASURE 4.2: Measurement results regarding AI system trustworthiness in deployment context(s) and across AI lifecycle are informed by input from domain… NIST AI RMF, MEASURE 4.3: Measurable performance improvements or declines based on consultations with relevant AI actors including affected communities, and field da… EU AI Act, Article 4: AI literacy EU AI Act, Article 9: Risk management system EU AI Act, Article 12: Record-keeping EU AI Act, Article 13: Transparency and provision of information to deployers EU AI Act, Article 14: Human oversight EU AI Act, Article 15: Accuracy, robustness and cybersecurity EU AI Act, Article 26: Obligations of deployers of high-risk AI systems EU AI Act, Article 27: Fundamental rights impact assessment for high-risk AI systems EU AI Act, Article 50: Transparency obligations for providers and deployers of certain AI systems EU AI Act, Article 72: Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems EU AI Act, Article 73: Reporting of serious incidents It is a vendor's assistant, used as supplied (Public tier; cites 1) It runs on an AI platform with the organisation's own data, without executing arbitrary code (Public tier; cites 1) It is configured on a low-code or no-code builder and acts on real organisational data (Public tier; cites 1) It generates and executes code with local or cloud privileges (Public tier; cites 1) It is built in-house: the organisation controls its identity, tools and boundaries (Public tier; cites 1) It follows fixed rules, with no reasoning (Public tier; cites 4) It retrieves information and recommends actions; a person acts (Public tier; cites 2) It executes actions itself (Public tier; cites 3) It works in one domain's data (Public tier; cites 2) It works across several domains or systems (Public tier; cites 5) It connects to external tools or services across a trust boundary (Public tier; cites 3) Several agents coordinate inside the organisation (Public tier; cites 4) Agents operate across organisational boundaries or disparate stacks (Public tier; cites 4) There is a published protocol or communication layer between agents (Public tier; cites 3) The person operates: every action is prompted and controlled by them (Public tier; cites 1) The agent suggests; the person reviews and approves each action (Public tier; cites 1) The agent handles routine tasks; the person is consulted on exceptions (Public tier; cites 1) The agent works independently; the person approves critical decisions only (Public tier; cites 1) The agent has full autonomy within boundaries; the person monitors (Public tier; cites 2) Its purpose and permitted tasks are stated in writing (Public tier; cites 5) Its autonomy limits and the tools it may use are defined (Declared tier; cites 3) Its limits and known failure cases are documented for those who use it (Public tier; cites 3) What it can reach is enumerated: scopes, permissions, tools (Public tier; cites 3) Its authorisation is published as metadata that anyone can read (Public tier; cites 4) It asks for narrower access than the whole account (Public tier; cites 5) It has its own identity, separate from any person's (Declared tier; cites 3) Its identity is cryptographic and can be checked by others (Public tier; cites 1) Its tokens are bound to the service they were issued for and are not passed on (Evidenced tier; cites 7) The organisation keeps a registry of its agents (Declared tier; cites 6) Each agent has a named owner (Declared tier; cites 3) Agents are retired by a defined process (Declared tier; cites 4) A named executive or body is accountable for the organisation's agents (Public tier; cites 6) Roles and responsibilities for AI risk are documented (Declared tier; cites 3) A governance policy for agents is published (Public tier; cites 9) Agents and use cases are classed by risk (Declared tier; cites 9) The laws that apply to it are identified (Declared tier; cites 3) New agents pass an approval or review before they run (Declared tier; cites 3) High-impact actions need a person's approval (Public tier; cites 6) There is a way to pause or stop it (Declared tier; cites 3) There is a defined escalation path (Declared tier; cites 3) Its actions are logged (Declared tier; cites 5) The log is tamper-evident and kept for a stated time (Evidenced tier; cites 4) It is monitored in operation (Declared tier; cites 8) Anomalies are detected in real time and raise alerts (Evidenced tier; cites 6) A limit on it is enforced by something outside its own reach (Public tier; cites 5) A limit on it is a setting that its own account could change (Public tier; cites 0) A limit on it is a rule in prose (Public tier; cites 1) Policy is enforced as machine-readable rules (Declared tier; cites 3) The difference between what it can reach and what it is for is stated (Public tier; cites 0) Test or evaluation results are published (Public tier; cites 6) It is tested for safety and security, including by attack (Declared tier; cites 4) People who did not build it take part in assessing it (Declared tier; cites 1) There is an incident process for agents (Declared tier; cites 5) Incidents and errors are communicated to those affected (Public tier; cites 3) There is a plan for a failure of a third party it depends on (Declared tier; cites 1) It tells the people it talks to that it is an AI (Public tier; cites 1) There is a channel to report problems with it or contest its output (Public tier; cites 5) The data it uses is described (Public tier; cites 4) There are data quality rules for what it reads (Declared tier; cites 4) Its privacy risk has been examined (Declared tier; cites 2) The models and third-party components it uses are listed (Public tier; cites 2) Third-party components are monitored and have risk controls (Declared tier; cites 4) A public certificate or audit report covers it (Public tier; cites 2) Compliance evidence is produced continuously, ready for a regulator (Evidenced tier; cites 3) There is a stated strategy for agents (Public tier; cites 7) The people who work with it are trained (Declared tier; cites 8) Its value is measured (Declared tier; cites 14) It is improved on a regular cycle (Declared tier; cites 7) The organisation's risk management covers agents (Declared tier; cites 5) What is the agent built on? Q 01 · freedom · 5 provisions in 1 instrument Does it act, or only answer and recommend? Q 02 · freedom · 9 provisions in 2 instruments How far does it reach? Q 03 · freedom · 10 provisions in 4 instruments Does it work with other agents? Q 04 · freedom · 10 provisions in 4 instruments What is the person's role? Q 05 · freedom · 6 provisions in 2 instruments Is what it is for written down? Q 06 · governance · 9 provisions in 4 instruments Does it have its own identity and only the ac… Q 07 · governance · 19 provisions in 4 instruments Is it in a registry, with an owner? Q 08 · governance · 11 provisions in 5 instruments Who is accountable for it? Q 09 · governance · 9 provisions in 3 instruments Is there a policy that governs it? Q 10 · governance · 24 provisions in 6 instruments Can a person step in or stop it? Q 11 · governance · 10 provisions in 7 instruments Is what it does logged? Q 12 · governance · 7 provisions in 3 instruments Is it watched while it runs? Q 13 · governance · 14 provisions in 6 instruments What stands between it and what it should not… Q 14 · governance · 8 provisions in 3 instruments Is it tested, and are the results shown? Q 15 · governance · 10 provisions in 3 instruments What happens when it goes wrong? Q 16 · governance · 9 provisions in 4 instruments Do people know it is an AI, and can they answ… Q 17 · governance · 6 provisions in 3 instruments What data does it use, and under what rules? Q 18 · governance · 7 provisions in 5 instruments What does it depend on from others? Q 19 · governance · 6 provisions in 2 instruments Has anyone independent checked? Q 20 · governance · 4 provisions in 3 instruments Is the organisation behind it ready? Q 21 · governance · 40 provisions in 7 instruments Lit: the 17 indicators with evidence for this agent, the questions they answer and the provisions they reach.
Every answer, with its source
What is the agent built on?
Not evidenced. It is a vendor's assistant, used as supplied.Not evidenced. It runs on an AI platform with the organisation's own data, without executing arbitrary code.Not evidenced. It is configured on a low-code or no-code builder and acts on real organisational data.As shipped. It generates and executes code with local or cloud privileges. It runs Claude Code sessions in a cloud virtual machine. Source (documented)Not evidenced. It is built in-house: the organisation controls its identity, tools and boundaries.Does it act, or only answer and recommend?
Not evidenced. It follows fixed rules, with no reasoning.Not evidenced. It retrieves information and recommends actions; a person acts.As shipped. It executes actions itself. It clones the repository, makes changes and pushes branches. Source (documented)How far does it reach?
Not evidenced. It works in one domain's data.As shipped. It works across several domains or systems. The repository, the shell and the code host. Source (documented)As shipped. It connects to external tools or services across a trust boundary. Sessions reach package registries and other allowlisted domains. Source (documented)Does it work with other agents?
Available, if the operator turns it on. Several agents coordinate inside the organisation. Subagents, as in the local product. Source (documented)Not evidenced. Agents operate across organisational boundaries or disparate stacks.Not evidenced. There is a published protocol or communication layer between agents.What is the person's role?
Not evidenced. The person operates: every action is prompted and controlled by them.Not evidenced. The agent suggests; the person reviews and approves each action.Not evidenced. The agent handles routine tasks; the person is consulted on exceptions.As shipped. The agent works independently; the person approves critical decisions only. The person starts a task and reviews the branch or pull request it produces. Source (documented)Not evidenced. The agent has full autonomy within boundaries; the person monitors.Is what it is for written down?
As shipped. Its purpose and permitted tasks are stated in writing. The vendor states what cloud sessions are for. Source (documented)Available, if the operator turns it on. Its autonomy limits and the tools it may use are defined. A cloud environment sets network access, variables and a setup script. Source (documented)Not evidenced. Its limits and known failure cases are documented for those who use it.Does it have its own identity and only the access it needs?
As shipped. What it can reach is enumerated: scopes, permissions, tools. A published deployment shape lists 15 capabilities, 13 of them observed on the thing itself. Source (documented)Not evidenced. Its authorisation is published as metadata that anyone can read.As shipped. It asks for narrower access than the whole account. GitHub credentials never enter the session’s machine; a proxy attaches them on the server. Source (documented)Not evidenced. It has its own identity, separate from any person's.Not evidenced. Its identity is cryptographic and can be checked by others.As shipped. Its tokens are bound to the service they were issued for and are not passed on. A stored key is added by the proxy after a request leaves the session, for the hosts listed. Source (documented)Is it in a registry, with an owner?
Not evidenced. The organisation keeps a registry of its agents.Not evidenced. Each agent has a named owner.Not evidenced. Agents are retired by a defined process.Who is accountable for it?
Not evidenced. A named executive or body is accountable for the organisation's agents.Not evidenced. Roles and responsibilities for AI risk are documented.Is there a policy that governs it?
Not evidenced. A governance policy for agents is published.Not evidenced. Agents and use cases are classed by risk.Not evidenced. The laws that apply to it are identified.Not evidenced. New agents pass an approval or review before they run.Can a person step in or stop it?
As shipped. High-impact actions need a person's approval. Work arrives as a branch for a person to review. Source (documented)Not evidenced. There is a way to pause or stop it.Not evidenced. There is a defined escalation path.Is what it does logged?
Not evidenced. Its actions are logged.Not evidenced. The log is tamper-evident and kept for a stated time.Is it watched while it runs?
Not evidenced. It is monitored in operation.Not evidenced. Anomalies are detected in real time and raise alerts.What stands between it and what it should not do?
As shipped. A limit on it is enforced by something outside its own reach. With the default (Trusted) network access, sessions reach allowlisted domains "and nothing else through the session’s network". Source (documented)As shipped. A limit on it is a setting that its own account could change. Two capabilities in the published shape are limited by a setting. Source (documented)Not evidenced. A limit on it is a rule in prose.Not evidenced. Policy is enforced as machine-readable rules.As shipped. The difference between what it can reach and what it is for is stated. The published shape names which capabilities are unbounded. Source (documented)Is it tested, and are the results shown?
Not evidenced. Test or evaluation results are published.Not evidenced. It is tested for safety and security, including by attack.Not evidenced. People who did not build it take part in assessing it.What happens when it goes wrong?
Not evidenced. There is an incident process for agents.Not evidenced. Incidents and errors are communicated to those affected.Not evidenced. There is a plan for a failure of a third party it depends on.Do people know it is an AI, and can they answer back?
Not evidenced. It tells the people it talks to that it is an AI.Not evidenced. There is a channel to report problems with it or contest its output.What data does it use, and under what rules?
Not evidenced. The data it uses is described.Not evidenced. There are data quality rules for what it reads.Not evidenced. Its privacy risk has been examined.What does it depend on from others?
As shipped. The models and third-party components it uses are listed. The product and its model family are named. Source (documented)Not evidenced. Third-party components are monitored and have risk controls.Has anyone independent checked?
As shipped. A public certificate or audit report covers it. The vendor points to a SOC 2 Type 2 report and an ISO 27001 certificate at its trust centre; they cover the vendor, not a user’s deployment. Source (documented)Not evidenced. Compliance evidence is produced continuously, ready for a regulator.Is the organisation behind it ready?
Not evidenced. There is a stated strategy for agents.Not evidenced. The people who work with it are trained.Not evidenced. Its value is measured.Not evidenced. It is improved on a regular cycle.Not evidenced. The organisation's risk management covers agents.The vault
This scan, its evidence list, its grant and the questions it was made against are kept in a public sgit vault (kq47p50t, published 2026-11-10). Anyone can read it with this key:
sgit_public_read_8996af6ecc712b76dfb7a34f4b820d2e89d066ade22bf910e02b7a5ea39d9fdc:kq47p50t
With sgit : sgit clone sgit_public_read_8996af6ecc712b76dfb7a34f4b820d2e89d066ade22bf910e02b7a5ea39d9fdc:kq47p50t. The key reads; it cannot write. An operator who wants to add what only they hold forks the vault into a private one.
