The Employee Can Open the File. Somansa Says the Agent Still Might Not Be Allowed To.

Three dates, and what each one actually confirms

Newsis and DailySecu, Korean security trade outlets, both carried coverage this record can trace to 26 August 2026, describing Somansa as having announced that day that it had launched a security solution to find and control so called shadow AI agents, AI agents installed on employee PCs without company approval that use internal files and systems. The phrasing this record found repeated across independently phrased search passes, rendered from Korean, is close to a direct quote: Somansa announced on the twenty sixth that it had launched Privacy i AIDR. This record's own verification converges on 26 August 2026 as the date Somansa itself is reported to have stated the launch, and uses that as the event date this piece analyses. A separate characterization exists, describing Somansa as having said the launch itself occurred a day earlier, on 25 August 2026, distinct from the date of the announcement about it. This record could not independently confirm that specific one day distinction, because direct fetch of the source carrying it was blocked and search indexing did not surface language distinguishing an announcement date from an underlying launch date, so this record does not assert the 25 August date and states plainly that the earlier date could not be confirmed rather than treating it as settled either way. This record could not independently locate English language international coverage of the launch distinct from the Korean trade press already cited, and does not assert that broader coverage occurred on any specific date. What this record does not do, regardless of which of the two Korean dates is more precise, is treat 28 August 2026, the date this record itself was written, as the event date. The current Moona Radar date is when this record was verified. It is not when Somansa's product launched.

The product itself is not presented in the reporting this record could reach as an invention with no history. An earlier preview of Somansa's plans for the ISEC 2026 security conference in Seoul, corroborated across independently phrased search passes, described a two track strategy: WebKeeper AI DLP on the network side, already deployed to banks and government agencies since 2023 according to that same coverage, and a Privacy i AI EDR on the endpoint side, described at that earlier point as controlling malicious agent behavior, including prompt injection and illegal or violent prompts, and personal information leakage. That earlier framing names different specific behaviors than the three functions, asset management, activity visibility and execution permission management, that August's Privacy i AIDR coverage names. This record treats those as two separate claims about the same product lineage at two different points in time, not as one continuous, fully corroborated feature set, and does not assume the earlier claim still holds inside the August release without evidence that it does.

What Privacy i AIDR is reported to actually be

The reported core move is adding AI detection and response, AIDR, on top of Somansa's existing endpoint detection and response product. Coverage this record could reach draws the distinction plainly: existing EDR focuses on detecting hackers, malware and insider activity on a PC; AIDR adds the AI agent's own behavior as a newly managed category alongside those. Three functions are named consistently across the sources this record could reach: AI agent asset management, meaning an inventory of what AI agents are present on a given endpoint; activity visibility, meaning logging what those agents do; and execution permission management, meaning restricting what an identified agent may use. The stated purpose for the product as a whole is finding and controlling shadow AI agents, defined in the reporting as agents installed on employee machines without company approval that use internal files and systems, a framing that treats the unapproved, ungoverned agent as the problem the product is built to surface before addressing what any specific agent may do once it is found.

Which agents it says it can see, and what that claim does not establish

The reported agent coverage names Claude, OpenAI and Gemini related agents specifically, alongside open source and self developed, meaning custom internally built, agents. This record treats that as the corroborated claim: coverage across the major hosted assistant ecosystems plus an open category for anything built in house or from open source components. One search pass this record ran additionally characterized that open category as including agents downloaded from platforms such as Hugging Face, a detail more specific than the open source framing repeated elsewhere. This record could not reproduce that specific platform name across additional independently phrased passes, so it preserves the claim as reported by that one pass rather than promoting it to the same corroboration level as the Claude, OpenAI and Gemini names, and does not claim universal AI agent detection on the strength of either.

What none of the reporting this record could reach documents is the mechanism itself. An authorization system can only assign a narrower policy to a governed subject if it can reliably identify that subject as distinct from an ordinary application, a local large language model runtime running with no agentic wrapper at all, a browser extension, a command line coding agent, or a custom process an employee wrote themselves. Nothing this record could reach states whether Privacy i AIDR identifies an agent by a running process's binary signature, a publisher certificate, a known executable name, observed network behavior, a driver level hook into process creation, or some other means entirely. This record states plainly, and preserves rather than fills in: agent identification mechanism, unknown.

Execution permission management, read as precisely as the evidence allows

This is the claim this record exists to test, because it is the strongest available public evidence of an Agent Authority principle Moona Intelligence has so far verified mainly at the cloud identity layer. Korean reporting states that, according to business purpose, an administrator can restrict which files, programs and system permissions an AI agent may use, and frames that restriction as a way to reduce misuse that could otherwise follow from an agent holding more access than its task requires. That sentence is precise about the dimensions, files, programs and system permissions or resources, and this record does not extend the claim to dimensions the reporting does not name, such as network destination, registry access, USB device access, or cloud drive connections, none of which this record found stated for this specific product capability, distinct from Somansa's separate, longer standing Privacy i data loss prevention channel controls over USB, printing, Wi Fi and Bluetooth, which this record treats as belonging to the base DLP product rather than to the AIDR agent permission claim specifically.

What business purpose actually means as a configuration mechanism is not documented in anything this record could reach. It could be a free text description an administrator types when creating a policy, a fixed set of purpose categories the product ships with, a mapping tied to the agent's own declared identity or class, a data classification scheme, or an assignment tied to a specific business application. This record does not infer which, and separately, it keeps the purpose used to configure a given restriction distinct from proof that the purpose itself was set by someone entitled to make that determination for the resource in question, a distinction this record's own coverage of Okta's Cross App Access already found undocumented at the software as a service layer and does not assume is any more settled here.

The unit the policy actually operates on is the specific detail this record most wants and least has. Possible units include a specifically named agent, a process or executable, a publisher or cryptographic hash, a pairing of a specific user and a specific agent, a broader agent class, a file path, a file classification, a named program, or a named system resource. Nothing this record could reach specifies which of these Privacy i AIDR actually implements, and this record does not round the claim up to whichever unit would make the strongest story. The publicly defensible claim, stated at the level the evidence actually supports, is narrower and still consequential: Somansa reports that an administrator can configure agent specific access restrictions over files, programs and system permissions. That is what this record asserts. It does not assert a specific enforcement unit beneath that.

What happens when an agent hits a restriction, and what remains unproven about when

Visibility and enforcement are different claims, and this record keeps them apart rather than reading one as evidence of the other. On visibility, the reporting this record could reach is specific: the product records an AI agent opening or deleting a file and accessing an internal system, and a security officer reviewing that log can identify activity that risks exposing personal or confidential information or altering a file, and can then intervene in real time. That sentence structure, log first, human review second, real time control as a consequence of that review, describes a detection and response loop, which is what the AIDR name itself claims, rather than a described pre execution gate that blocks a file open before it happens. Execution permission management is named as a separate, third function alongside asset management and activity visibility, which suggests some restriction is evaluated before or at the moment an agent attempts an action rather than purely after the fact through log review, but nothing this record could reach states precisely where in that sequence the check occurs: whether a protected file open is blocked before the file is actually opened, whether a write or delete is specifically intercepted while an open for reading is treated differently, whether a program launch itself is what gets intercepted, or whether the mechanism is closer to a fast detect and terminate loop than to a gate placed ahead of the action.

International coverage of AI agent endpoint enforcement in general, not confirmed by this record as specific to Somansa's own material, tends to describe this class of product as operating at the operating system level. This record treats that framing as a secondary interpretation rather than as Somansa's own confirmed architecture, because this record could not independently reach Somansa's technical documentation to establish the topology directly. Correspondingly, this record does not describe Privacy i AIDR as performing kernel level enforcement, rewriting access control lists, acting as a reference monitor, using eBPF, implementing mandatory access control, or providing inline data loss prevention enforcement, because none of those specific mechanisms is established by anything this record could reach. What is established is narrower: an administrator configured restriction on files, programs and system permissions an agent may use, and a logging and real time response capability layered on top of it. This record states the narrower claim rather than the stronger one.

Whether the agent's authority is actually narrower than the human account's own

This is the distinction underneath everything else in this record, and it is the reason this development belongs in Moona Intelligence's Authority Provenance coverage rather than in a shorter note about a product launch. An employee's own operating system account on a company machine already carries whatever file, program and system permissions that account holds. An AI agent process that runs under that same account, whether a hosted assistant's local client, a coding agent, or a custom script, does not automatically have to inherit the full reach of that account merely because it is running as that user. Somansa's reported capability, an administrator restricting which files, programs and system permissions an agent specifically may use, is evidence that at least one vendor is building a policy layer meant to sit between the human account's own standing permissions and what a given agent process is actually permitted to touch.

What this record could not independently establish is whether that policy layer can enforce a restriction the operating system's own account permissions would otherwise allow, meaning whether the product can actually stop an agent from doing something the human user running it is technically permitted to do. The reporting is consistent with a narrowing, attenuation shaped model, language describing the restriction as reducing misuse from an agent holding more access than necessary reads as start from what the account could otherwise reach, then subtract for the agent, rather than as a description of an independently constituted allow list the agent must qualify for from zero. This record states that as the reporting's apparent shape, not as a confirmed architecture, because no source reviewed here states the composition explicitly enough to call it verified either way. If independently confirmed against Somansa's own technical material, an agent's authority sitting strictly beneath the operating system account it runs under, for governed files, programs and system resources, would be materially strong evidence extending Moona Intelligence's existing Authority Provenance thesis, already verified at the software as a service and cloud identity layer through Okta's Cross App Access, into the endpoint itself. This record does not manufacture that confirmation. It states the narrower, defensible claim: Somansa provides administrator configured, per agent endpoint permission management over files, programs and system resources, and preserves the stronger inheritance narrowing claim as consistent with, but not proven by, the evidence this record could reach.

Why a local agent matters even though it never touches an identity provider

Moona Intelligence's own coverage of Okta's Cross App Access and of execution time authority controls across cloud hosted agent runtimes both operate at a layer above this one: a connection between two applications authorized through an enterprise identity provider, or a tool call intercepted before it reaches a cloud hosted service. An AI agent running locally on an employee's own machine, reading a file, launching a program, or touching a local system resource, can complete that action without ever crossing an OAuth exchange, an enterprise agent identity and access management layer, an MCP gateway, or a cloud API gateway. None of the controls this record has already verified at those layers has anything to inspect in that moment, because the action happened before any of them were ever engaged. That is the specific, narrower market contribution this record credits to the endpoint layer Somansa's product claims to occupy: not that cloud and identity layer controls are categorically unable to govern a local agent, which this record does not assert, but that a local agent's file and system level actions are consequential and can occur upstream of every cloud or identity layer control point this corpus has verified so far, which is exactly why an endpoint specific policy layer is a distinct and non redundant place to look for this same Agent Authority question.

What the activity log is actually reported to record

The reporting names specific activity types the product logs: an agent opening a file, an agent deleting a file, and an agent accessing an internal system. It states that a security officer uses those logs to identify activity that risks personal or confidential information exposure or file tampering, and can act on that in real time. It does not, in anything this record could reach, specify the exact fields a given log entry carries beyond the activity type itself, meaning this record could not confirm whether an entry identifies the specific agent by name, the human user, the process, the exact file or resource touched, a timestamp, a policy decision, an allow or deny outcome, or a stated reason, as distinct fields. This record does not infer that fuller schema. It also does not describe these logs as signed, tamper evident, non repudiable, or as authorization receipts in the sense Moona Intelligence has used that term for other records, because nothing reviewed here establishes any of those specific properties. What is documented is activity evidence, a record that something happened. It is not documented as authorization decision evidence, a record proving a specific access was evaluated against a specific policy and why, and this record keeps those two categories separate.

The Authority Provenance ledger

Authority grantor. Documented only in general terms. Reporting attributes the ability to configure agent specific file, program and system permission restrictions to an administrator, and attributes log review and real time intervention to a security officer, without specifying whether these are the same role, a formal security administrator title, a DLP administrator, or an endpoint administrator specifically. This record does not name a more specific role than the evidence supports, and preserves the underlying question, whether the person technically able to configure this policy is the same party organizationally entitled to decide that an AI agent may access a given sensitive file or system resource, as unknown, consistent with the same gap this record's own coverage of Okta's Cross App Access already found at a different layer.

Mandate or basis. Reported as business purpose. What business purpose means as a technical configuration input, an administrator's free text description, a fixed policy category, an agent identity or class mapping, a data classification, or a task or application assignment, is undocumented in anything this record could reach. This record keeps the purpose used to configure a restriction distinct from proof that the purpose itself carries legitimate authority over the underlying resource, and does not assume the second from the first.

Delegated scope. Documented at the level reporting actually states it: files, programs, and system permissions or resources. This record does not extend that scope to network destinations, data classification, registry keys, process creation controls, USB devices, or cloud drive connections for this specific AIDR capability, because none of those dimensions is stated for it in anything this record could reach, and keeps Somansa's separate, previously established DLP channel controls, USB, printing, Wi Fi and Bluetooth, apart from this claim rather than folding them into it.

Explicit limits. Reporting frames the restriction as reducing misuse from an agent being granted more access than necessary, language this record reads as consistent with an attenuation model, narrowing down from what an account could otherwise reach, rather than as a confirmed description of an independently constituted allow list built up from zero. This record states that as the apparent shape of the claim rather than as verified architecture, because no source reviewed here states the underlying default, allow first and subtract, or deny first and explicitly permit, plainly enough to call either one confirmed.

Inherited permissions and assumptions. This is the central open question. Somansa's own material, where this record could reach it, does not state whether the product can enforce a policy the operating system account itself would not otherwise allow, meaning whether the product introduces privilege mechanisms beyond narrowing what the account could already reach. The analytically likely shape, consistent with how endpoint agents generally operate and with the language reported here, is that Privacy i AIDR narrows the surrounding account's own authority rather than granting an agent capability the account lacks, which would mean agent authority stays bounded at or beneath the human account's own authority for the resources this policy actually governs. This record states that as the probable, not the confirmed, shape, because nothing reviewed here states the composition explicitly, and marks it as the single most consequential fact an editor with access to Somansa's own technical documentation should confirm directly.

Revocation or modification. Undocumented. Nothing this record could reach states how quickly a changed policy affects an agent process already running, a file handle an agent already has open, an active operation already underway, or data an agent has already cached locally. This record does not infer instant revocation and preserves the gap as unknown rather than assumed in either direction.

Challenge authority. Undocumented as a distinct human approval workflow. Nothing this record could reach describes a hold, an approval step, a temporary exception, or an administrator override channel distinct from an administrator's own ordinary ability to edit policy going forward. The real time control described in the reporting is a security officer acting on a policy or log finding, which this record classifies as automated policy enforcement paired with human initiated response, not as a human challenge to a decision already made by the system on a specific action.

Recovery. Undocumented. Blocking or interrupting an access attempt, where the product is confirmed to do so, prevents that particular attempt from continuing. Nothing this record could reach describes a mechanism for reversing data an agent already read, a file already deleted, or a log or system state an agent already altered before detection occurred, and this record does not assume Somansa has separately built file restoration, quarantine, or rollback capability into this product without evidence that it has.

Provenance evidence quality. Layered rather than uniform. The existence of the product, its three named functions, its shadow AI agent framing, and its named agent coverage across Claude, OpenAI and Gemini related agents plus open source and custom agents are corroborated across multiple independently phrased search passes converging on consistent detail from Newsis and DailySecu specifically, and this record treats that as medium confidence manual review evidence rather than as a directly fetched primary source, because every direct fetch attempt against the underlying pages was blocked in this session. The Hugging Face specific detail surfaced in only one pass and is marked lower confidence accordingly. The exact enforcement topology, the unit the permission policy operates on, the agent identification mechanism, the log schema's full field set, and whether the product can enforce below the host operating system account's own permissions are each undocumented in anything this record could reach, and this record states each of those gaps as a gap rather than filling it with the stronger claim international coverage of this product category sometimes assumes.

Reco Browser Guard: a third boundary, mediated by the browser rather than the endpoint or the cloud

Reco announced general availability of Browser Guard on 1 September 2026, described in its own material as a runtime security layer against prompt injection, data leakage and unauthorized actions triggered through browser based AI use. The named scope is wide: AI assistants, copilots, coding agents, autonomous workflows, shadow AI and personal AI accounts, all reached through the browser rather than through a cloud hosted agent runtime or a locally installed endpoint process. Reco's own framing states that most of this activity now starts in the browser, upstream of the tools a security team already monitors, which is the same observation this record makes about a local endpoint agent completing an action before any identity provider or cloud gateway is ever engaged, applied to a different surface. The stated mechanism is that Browser Guard inspects prompts and agent activity, correlates that activity with Reco's own context on the user, the data and the business environment, and adds security context by identifying the user, data, destination, account type and business purpose behind every interaction, giving a security team the ability to detect, guide, block or stop an action before it exposes data or initiates an unauthorized workflow. Reco's own material separately states Browser Guard exposes the AI tools, browser extensions and personal accounts employees use outside approved channels, distinguishing a corporate account from a personal one and surfacing whether business data is shared in it. This record keeps that exposure claim, a discovery and visibility capability, distinct from the detect, guide, block and stop spectrum named above; nothing this record could reach states that every discovered tool, extension or personal account is placed under active enforcement rather than only made visible, and this record does not equate discovery with governance for any category Reco's own material does not separately name as enforced.

What Reco's own privacy policy independently confirms, and what it does not

Reco's own privacy policy documents the underlying architecture more precisely than the launch announcement's own product language does. It states Browser Guard is a Chrome extension, deployed by an enterprise to its own managed browsers, and that it collects authentication and session signals, account identifiers, SSO redirect events, hashed AI prompt metadata rather than the prompt text itself, device fingerprint data and an inventory of installed browser extensions, sending that data to the organization's own Reco tenant. This record treats that as the confirmed technical shape of the product: a browser extension operating inside a managed deployment, not a network proxy, an operating system level hook, or a cloud API gateway. It is also, on the same evidence, a narrower shape than plain browser wording might suggest. This record found no material, from Reco's own site or from independent trade press, stating that Browser Guard supports a browser other than Chrome, and does not extend the claim to Firefox, Edge or Safari absent that evidence, the same discipline this record applies to Somansa's own undocumented agent identification mechanism above. The hashed rather than plaintext treatment of prompt metadata is a real, verifiable privacy design choice; it also means this record has no basis to claim Browser Guard evaluates a prompt's actual semantic content against policy, as distinct from evaluating metadata about that prompt, and states that distinction rather than assuming the stronger reading.

Business purpose, again a contextual input rather than a bound mandate

Reco's own material names business purpose as one of five fields, alongside user, data, destination and account type, that Browser Guard identifies behind an interaction. This is the same term this record already examined for Somansa's own product above, and this record applies the same caution here rather than a weaker one because a second vendor uses the same word. Nothing this record could reach states how Reco's own product actually derives business purpose: whether it is a fixed category an administrator configures, a mapping tied to the destination or application a request reaches, a data classification scheme, a workflow or task label, or something the user or the agent itself supplies that Browser Guard treats as reported rather than independently verified. If business purpose is agent or user self declared without a trusted binding to an administrator's own policy, it functions as contextual information a policy engine considers, not as durable, independently constituted evidence of a mandate, the same limitation this record already states for Somansa. This record does not assume the stronger reading for either product, and marks Reco's own business purpose provenance as undocumented rather than inferring an administrator source it did not find stated.

Detect, guide, block, stop: what changes in the browser, and what is not established downstream

Reco's own material names four outcomes across a spectrum, detect, guide, block and stop, without stating, for any specific supported category, AI assistants, copilots, coding agents, autonomous workflows, shadow AI or personal accounts, which of those four outcomes actually applies to it. This record does not assume every named category reaches the strongest end of that spectrum, block or stop, absent a specific statement that it does, and treats the spectrum as Reco's own stated range of possible outcomes rather than as a guarantee that every detected activity is actively blocked. Independent trade coverage this record could reach through search corroborates a phased rollout consistent with that reading: an AI Runtime expansion Reco announced ahead of Black Hat USA 2026, dated 28 July 2026, already added browser level enforcement and discovery capability, and this 1 September 2026 release is described as extending that into full prompt, response and tool call analysis and blocking through a policy engine evaluating each in real time. This record treats the two dates as one continuing product development, not as two independent developments, consistent with how it already reads Somansa's own earlier ISEC 2026 preview against its own August launch above. What this record could not establish from anything it could reach is the technical mechanism behind a block or a stop: whether a request is cancelled before it leaves the browser, a form submission is prevented, a navigation is blocked, an extension event is intercepted, a network request from the page is prevented, a session is terminated, content is redacted, or some other mechanism entirely. This record does not equate browser level blocking with cancellation of a downstream effect unless a specific source states that the intercepted request itself never reached its destination, and states the mechanism as undocumented where it could not confirm which of these occurs.

The managed browser boundary, and what sits outside it

Reco's own privacy policy confirms the boundary this record treats as decisive: Browser Guard is a Chrome extension deployed to an enterprise's own managed browsers. That is a real, verifiable deployment topology, and this record credits it precisely as that, not as evidence of broader reach. Nothing this record could reach states what happens when the same user or agent reaches an AI service through an unmanaged personal browser, a local command line agent that never opens a browser tab at all, a direct API call carrying its own OAuth token or API key, a Model Context Protocol client operating outside the browser, or a desktop agent application, and this record does not assume Browser Guard mediates any of those paths absent a specific statement that it does. Reco's own broader platform, verified separately in this record's own coverage of Reco's State of Agent Security 2026 telemetry, connects to SaaS platforms through API integrations rather than by intercepting browser traffic, a different mechanism this record does not fold into Browser Guard's own managed browser enforcement without evidence that the two share one mediation point. The correct claim this record states, precisely because Browser Guard's own confirmed architecture is a browser extension rather than a network wide or identity wide control point, is narrower than complete mediation: Browser Guard mediates supported activity that traverses the managed browser path it is installed in, and this record does not extend that claim to activity that reaches an AI service by another route, the same reachability discipline this record's own coverage of environment boundaries elsewhere already applies to network egress and credential scope.

Reco Browser Guard's Authority Provenance ledger

Moona Intelligence applies the same nine dimensions to Reco Browser Guard that this record applies to Somansa's own Privacy-i AIDR above, reading a vendor's own account of a generally available product for what it documents rather than for what a mature, independently audited deployment would need to add.

Authority grantor. Undocumented beyond an enterprise's own administrator deploying the Chrome extension to managed browsers. Reco associating a browser session with an identified human user is not evidence that the same human, or the administrator who configured the policy, held organizational legitimacy to decide that a given agent action through that session was permitted, and this record states grantor legitimacy as unknown rather than inferring it from the ability to configure policy, the same reading it gives Somansa's own administrator role above.

Mandate or basis. Business purpose, named alongside user, data, destination and account type as identified context. Its representation and source are undocumented, as stated above, and this record does not treat an identified business purpose as durable evidence of a mandate absent a documented, trusted binding to administrator policy rather than to a self reported or inferred label.

Delegated scope. Documented at the level Reco's own material actually states it: destination, account, data, browser or session context, business purpose and policy. This record does not extend that scope to a specific agent tool, a tool's arguments, a specific backend API operation, or a monetary or use count limit, because none of those dimensions is stated for Browser Guard in anything this record could reach.

Explicit limits. A real time policy decision evaluating identity, data, destination, account type and business purpose together before a supported action proceeds, at the level of a browser mediated interaction rather than a specific tool call's arguments or a specific downstream API operation. This record could not verify a finer grained enforcement unit and does not assert one.

Inherited assumptions. Browser Guard's own framing targets exactly the collapse this record already names for Somansa at a different layer: that a browser session already authenticated to a destination is treated as sufficient authority for whatever an AI agent does through that session, that a personal account is treated as outside enterprise control because it is not centrally provisioned, and that a prompt appearing safe is treated as authorizing whatever downstream workflow follows it. Whether Browser Guard's own check actually evaluates an agent's specific action against policy, as opposed to gating access to a destination or an account category more broadly, is not established at the level of precision this record requires before stating the stronger reading, and this record does not assume it.

Revocation or modification. Undocumented. This record found no material describing how quickly a changed policy reaches an already active browser session, what happens to an in progress interaction when policy changes mid session, or how disabling the extension itself is protected against on a managed device. Each is stated unknown rather than assumed.

Challenge authority. Undocumented as a distinct human approval workflow. Reco's own guide outcome reads as an in browser prompt or warning directed at the user rather than a documented human in the loop approval, escalation or exception review step, and this record does not infer a hold or an approval queue from the word guide alone, the same discipline it applies to Somansa's own real time control language above.

Recovery. Undocumented, and this record does not assume it from the product's own preventive framing. Blocking or stopping an action before it completes, where Browser Guard is confirmed to do so, prevents that specific attempt; nothing this record could reach describes a mechanism for reversing an effect that already completed through a path Browser Guard did not intercept.

Provenance evidence quality. High for the product's existence, its 1 September 2026 general availability claim, and its named scope, user, data, destination, account type and business purpose context feeding a detect, guide, block or stop decision, corroborated across repeated, independently phrased search passes converging on consistent wording. High, and independently sourced from Reco's own privacy policy rather than its launch material, for the Chrome extension and managed browser deployment architecture and the specific signals it collects. Partial for which of detect, guide, block or stop applies to which named category, for the exact block or stop mechanism, and for business purpose provenance, since available material does not specify any of the three at the level this record requires before stating it as established. Unknown for grantor legitimacy, for revocation propagation timing, and for any independent security evaluation, since www.globenewswire.com and www.reco.ai were both blocked to direct fetch in this session's tooling environment, and this record found no independent technical documentation or third party security assessment beyond search convergence corroborating Reco's own material. An editor with unblocked access to Reco's own technical documentation, admin console and Chrome Web Store listing should confirm the mechanics above directly before any claim in this section is relied on beyond the manual review level recorded here.

CrowdStrike brings the same endpoint boundary to a major incumbent's own installed base

CrowdStrike unveiled Falcon Guardian on 1 September 2026 at Fal.Con 2026, its annual conference in Las Vegas, describing it as extending the existing, kernel level Falcon sensor into a dedicated control point for AI agent activity on managed Windows and macOS endpoints. CrowdStrike's own material names three capabilities: Agent Runtime Visibility, Agent Access Controls, and Runtime Detection and Response, each examined in turn below. This record reads Guardian's own contribution precisely: it does not introduce a new boundary the way Reco's Browser Guard does, mediating a surface, the browser, none of this record's other evidence reaches. It reinforces the exact boundary Somansa's own product already occupies, the managed endpoint, with independent evidence from a different vendor at a scale a smaller, single vendor claim cannot carry on its own. Where Somansa's own evidence rests on Korean trade press this record could not independently fetch, CrowdStrike is one of the largest incumbent endpoint security vendors, and its own decision to build a dedicated AI agent control point into its flagship sensor is itself evidence that the underlying distinction this record has argued since its Somansa material, an employee's own account being permitted to run software on a managed machine is not the same fact as a given AI agent process being permitted to run under that account, has reached beyond one specialized Korean vendor into mainstream endpoint security. This record does not treat that convergence as proof that the endpoint is the correct or only place to enforce this distinction; it reads it as evidence that more than one vendor, at more than one scale, has independently reached the same conclusion about where a check needs to sit.

Known, shadow and dormant: what Guardian actually discovers, and what remains unverified

CrowdStrike's own material states Guardian discovers known and shadow AI agents across managed Windows and macOS endpoints, providing a live inventory of every running and dormant agent, who deployed it, and its security status. This record preserves CrowdStrike's own four way distinction rather than collapsing it: a known agent is presumably one CrowdStrike's own catalog or policy already names; a shadow agent is one installed without company approval; a running agent is active at the moment of inventory; a dormant agent is present on the endpoint but not currently executing. What CrowdStrike's own material does not state, in anything this record could reach, is the underlying discovery mechanism: whether Guardian identifies an agent by a process's binary signature, a publisher certificate, a known executable or package name, observed behavior, a driver level hook into process creation, or some other means. This is the same gap this record already states as unknown for Somansa's own Privacy-i AIDR, and this record applies the identical caution here rather than assuming a more sophisticated mechanism merely because a larger vendor makes the claim. CrowdStrike separately states its sensors already detect more than 1,800 distinct AI applications across nearly 160 million instances within its existing customer base, a telemetry scale figure this record traces to CrowdStrike's own earlier account of its installed base rather than to a Guardian specific adoption metric, and reads as evidence of what the underlying Falcon sensor already sees across its endpoints generally, not as an independently audited count of Guardian deployments or of agents Guardian itself has discovered and classified.

A causal chain from prompt to downstream action, and why that is not the same as authority provenance

CrowdStrike's own material states Agent Runtime Visibility connects AI agent behavior directly to Falcon endpoint telemetry, establishing a causal chain from a user's prompt and identity through a tool call and skill use to every downstream system action. This is a materially different and stronger claim than anything this record has verified for Somansa's own product, which documents activity logging, not a reconstructed causal path from instruction to effect. This record credits the claim precisely as CrowdStrike states it and no further. Nothing this record could reach specifies how prompt provenance is actually collected, which specific tools or skills across which specific supported agent products Guardian can recognize by name, whether a spawned child process inherits the same causal chain as its parent or breaks it, how browser mediated or network based agent activity is associated back to the same chain, or whether an effect that lands on a remote SaaS application or a third party API remains attributable once it leaves the endpoint. Each is stated as undocumented rather than inferred. Separately, and critically, this record preserves a distinction the causal chain claim itself does not resolve: prompt provenance is not authority provenance. A reconstructed chain from a user's prompt to a downstream action proves what instruction actually initiated that execution, a real and valuable forensic property. It does not establish that the user who issued the prompt was organizationally entitled to authorize the action the agent then took, the same gap this record has already named for Somansa's own business purpose claim and for Reco's own identified user context above.

Agent access controls: which agent may run is a coarser decision than which action it may take

CrowdStrike's own material states Agent Access Controls define which AI agent types are permitted to run on managed endpoints, blocking unauthorized agents and translating governance policy into enforceable runtime controls. Nothing this record could reach specifies the exact granularity of that decision: whether it operates on a named agent product or type, a specific binary, a publisher certificate, a version, a specific user, a specific device, a computed risk score, a configuration profile, or a workspace, and this record does not assert a finer grained unit than CrowdStrike's own material actually names. This record keeps that decision distinct from a different and stronger claim it does not make: that a specific downstream action a permitted agent then attempts is itself authorized. Whether a given agent type may run on a managed endpoint at all is a coarser, earlier gate than whether one specific tool call, file access or system operation that running agent later attempts should proceed, and this record does not read CrowdStrike's own access control claim as reaching the second question, which is instead the question Continuous Identity for AI Agents, examined separately below, is built to answer.

Continuous Identity for AI Agents: real time action authorization, evaluated separately from Guardian's agent run decision

CrowdStrike unveiled Continuous Identity for AI Agents on 15 June 2026 at Identiverse 2026, a CrowdStrike Falcon Next-Gen Identity Security capability built on technology from CrowdStrike's acquisition of SGNL. CrowdStrike's own material states every agent is assigned a cryptographically verifiable identity based on the SPIFFE standard, an open workload identity standard, replacing static credentials such as API keys, and that every agent action is continuously authorized in real time based on who owns the agent, who is calling it, and the risk posture of their device, evaluated against native and third party risk signals on the Falcon platform. When an agent delegates to a sub-agent, CrowdStrike states that caller and ownership context is preserved through the chain rather than reset at each hop. Access is dynamically granted, denied and revoked under a Zero Standing Privilege model CrowdStrike's own material describes as eliminating standing privileges entirely, minting access only for the instant a specific action needs it. Administrators can define policy distinguishing agent types, such as a customer support agent from a code generation agent, with different levels of monitoring and step up verification, a term CrowdStrike's own material names without this record finding a specification of whether a given step up event presents a challenge to a human or triggers a further automated check. This record does not attribute this action level authorization mechanism to Falcon Guardian: nothing in the material available to this record states that Guardian's own agent run decision and Continuous Identity's own per action authorization decision are integrated into one evaluated outcome, and this record states that integration as undocumented rather than assumed, the same discipline the brief for this update requires. Read against this record's own Somansa material, Continuous Identity is closer in shape to Okta's Cross App Access, evaluated above, a real time authorization decision at the point an action is attempted, than to Somansa's own file, program and system permission restriction, and this record does not conflate the two products' different mechanisms merely because both originate from CrowdStrike.

SSF, named alongside SPIFFE, and the distinction between a standard CrowdStrike uses and a standard CrowdStrike is helping build

A verification pass run on 7 September 2026 checked specifically for what Continuous Identity's own June material states beyond the SPIFFE based identity claim already verified above, and found one further detail this record had not yet carried: CrowdStrike's own material names the Shared Signals Framework, SSF, alongside SPIFFE as one of the modern identity standards behind Continuous Identity, stating that every action is authorized in real time using modern identity standards including SPIFFE and SSF. Read next to that sentence, the same corroborated material separately states that CrowdStrike is helping advance standards including SSF and the Continuous Access Evaluation Profile, CAEP, to let real time security and identity signals move across modern environments, a sentence about CrowdStrike's own standards body participation rather than a claim about Continuous Identity's own shipped mechanism. This record keeps the two claims separate rather than collapsing them into one implementation fact. SPIFFE's own role in Continuous Identity is specific and already verified above: a cryptographic identity mechanism assigned to each agent. SSF's own role inside Continuous Identity's specific decision, as opposed to CrowdStrike naming it as one of the standards behind real time authorization generally and separately working to advance it industry wide, is not specified with the same precision anywhere this record could reach, and this record does not infer that SSF functions inside Continuous Identity the way, for example, Britive's own platform documents native SSF support consuming CAEP and RISC events to trigger session termination, a distinct product Moona Intelligence has already verified elsewhere in this corpus with a specific, checkable mechanism SSF's mention here does not yet carry. This record states SSF's own specific technical function inside Continuous Identity as undocumented beyond that naming rather than assumed, and does not treat naming a standard as equivalent to a documented implementation of it.

Runtime detection and containment: what stops, and what happens to an effect already committed

CrowdStrike's own material states Runtime Detection and Response detects attacks on agents and malicious agent behavior, reconstructs the full execution chain, and determines blast radius in real time. This record distinguishes that claim precisely from a different one it does not make on CrowdStrike's behalf: reconstructing an execution chain and determining blast radius are analytical and forensic capabilities, valuable for understanding what already happened, not, on anything this record could verify, a statement that a specific in progress action is halted before its effect commits. Agent Access Controls blocking an unauthorized agent is a claim about preventing an agent from running at all; it is a different claim from stopping one specific action a already running, otherwise authorized agent attempts mid execution, and this record keeps those two forms of blocking apart rather than treating either as evidence for the other. Nothing this record could reach states that Guardian can reverse a downstream effect that has already committed, a file already exfiltrated to a remote destination, an API call that already executed, or data already written to a system outside the endpoint's own reach, and this record does not import a rollback or recovery capability from the product's own preventive and detective framing.

What Guardian does not establish: complete mediation, and what sits outside the managed endpoint

CrowdStrike's own market framing positions the endpoint as uniquely positioned for AI agent security, since agent activity, CrowdStrike argues, ultimately executes on a device the Falcon sensor already instruments. This record does not accept that framing as independently established fact merely because CrowdStrike states it; it is CrowdStrike's own competitive positioning, and this record tests it against what Guardian's own confirmed architecture actually covers. Guardian's own material describes coverage of managed Windows and macOS endpoints running the Falcon sensor. This record found no material stating that Guardian mediates an AI agent that runs entirely in a remote or cloud hosted environment never touching a managed endpoint, a SaaS hosted agent, a direct API call carrying its own credential, a browser mediated interaction, a Model Context Protocol server operating remotely, a cloud worker process, an already issued credential used from outside the endpoint's own reach, or any activity from a device that is not enrolled and managed by CrowdStrike at all. CrowdStrike's own material states a Guardian AI Gateway, a centralized control point for enterprise AI traffic that would apply Falcon security context across every AI communication including MCP, is coming, described in future tense rather than as a shipped capability, and separately states it is expanding Guardian's reach through an integration with Google's own Agent Gateway for AI applications built on Google Cloud, a claim this record credits as CrowdStrike's own stated direction rather than as independently verified, complete coverage of every non endpoint path today. The correct claim this record states, precisely because Guardian's own confirmed architecture is an endpoint sensor rather than a network wide or identity wide control point, is narrower than complete mediation: Guardian mediates AI agent activity on managed endpoints running the Falcon sensor, and this record does not extend that claim to agent activity that never touches one, the same reachability discipline this record already applies to Reco's own managed browser boundary above.

Falcon Guardian's Authority Provenance ledger

Moona Intelligence applies the same nine dimensions to Falcon Guardian that this record applies to Somansa's own Privacy-i AIDR above.

Authority grantor. Undocumented beyond an enterprise's own Falcon administrator configuring which agent types may run. CrowdStrike identifying who deployed an agent is not evidence that the same person, or the administrator configuring policy, held organizational legitimacy to decide that a given agent should run on a given machine, and this record states grantor legitimacy as unknown rather than inferring it from administrative access, the same reading it applies to Somansa's own administrator role above.

Mandate or basis. A reconstructed causal chain from user prompt to downstream action. This record states plainly that prompt provenance is not authority provenance: the chain proves what instruction initiated an action, not that the prompting user was entitled to authorize it, and this record found no task, ticket, mission or workflow binding documented as a further mandate input.

Delegated scope. Documented at the level CrowdStrike's own material actually states it: which agent types may run, on which managed endpoints. This record does not extend that scope to a specific tool argument, a specific backend operation, or a monetary or resource limit, because none of those dimensions is stated for Guardian's own access control capability in anything this record could reach.

Explicit limits. An agent type level run or block decision, evaluated at the endpoint, distinct from and coarser than a specific downstream action's own authorization. This record could not verify a finer grained enforcement unit for Guardian itself and does not assert one.

Inherited assumptions. Guardian's own framing targets exactly the collapse this record has named repeatedly at other layers: that an employee's own account being permitted to run software is treated as sufficient permission for any AI agent process that happens to run under that account, and that an agent being allowed to run is treated as authorizing every action it subsequently takes. Whether Guardian's own Agent Access Controls evaluate anything beyond agent type and endpoint context, as opposed to the specific action an already running agent then attempts, is not established at the level of precision this record requires before stating the stronger reading, and this record does not assume it.

Revocation or modification. Undocumented for Guardian specifically. Nothing this record could reach states how quickly a changed access policy reaches an agent already running, or what happens to an in progress agent process when its permitted status changes mid session. Continuous Identity's own dynamic grant, deny and revoke model, examined separately above, is not documented as integrated with Guardian's own decision, and this record does not import one product's revocation behavior into the other.

Challenge authority. Undocumented as a distinct pre execution human approval workflow. CrowdStrike's own material describes Falcon Complete for Guardian and Falcon Adversary OverWatch for Guardian, both stated in future tense as forthcoming rather than shipped, as analyst led detection, investigation and response after an incident is flagged, which this record classifies as human initiated incident response, not as a human challenge to a specific action before it executes, the same distinction this record draws for Somansa's own security officer role above.

Recovery. Undocumented beyond containment. Runtime Detection and Response reconstructing an execution chain and determining blast radius are forensic and analytical capabilities; nothing this record could reach describes a mechanism for reversing a downstream effect that already committed outside the endpoint's own reach.

Provenance evidence quality. High for the product's existence and its three named capabilities, corroborated across repeated, independently phrased search passes converging on consistent wording from CrowdStrike's own press release and blog. Partial for availability: CrowdStrike's own material states Guardian was unveiled and introduced on 1 September 2026, and this record found no equally explicit general availability statement for Guardian's own endpoint runtime capability the way it found one for the earlier Falcon AI Detection and Response product, dated December 2025, so this record states Guardian's own availability precisely as unveiled rather than rounding it up to generally available. High that the Guardian AI Gateway, Falcon Complete for Guardian and Falcon Adversary OverWatch for Guardian are each stated in future tense as forthcoming rather than shipped. Unknown for the exact discovery mechanism, the exact access control granularity, prompt provenance collection, subprocess and cross surface causal chain inheritance, and any independent security evaluation, since www.crowdstrike.com was blocked to direct fetch in this session's tooling environment for every source cited, and this record found no independent technical documentation or third party assessment beyond search convergence corroborating CrowdStrike's own material. An editor with unblocked access to CrowdStrike's own Falcon Guardian data sheet, product documentation and admin console should confirm the mechanics above directly before any claim in this section is relied on beyond the manual review level recorded here.

Continuous Identity for AI Agents' Authority Provenance ledger

Moona Intelligence applies the same nine dimensions to Continuous Identity for AI Agents, kept as a separate ledger from Falcon Guardian's own above because nothing this record could reach documents the two as one integrated decision.

Authority grantor. Undocumented beyond an enterprise's own Falcon administrator configuring authorization policy. CrowdStrike evaluating who owns an agent and who is calling it identifies parties to an action; it does not, on anything this record could verify, establish that the identified owner or caller held organizational legitimacy to authorize the specific action evaluated, and this record states grantor legitimacy as unknown.

Mandate or basis. Real time context: agent owner, caller identity, and device risk evaluated against native and third party signals on the Falcon platform. This record found no task, ticket, mission or workflow binding documented as an additional mandate input, and does not treat an evaluated risk score as evidence of organizational entitlement to act.

Delegated scope. Documented at the level CrowdStrike's own material actually states it: agent owner, caller, and device risk, with caller and ownership context preserved across a delegation to a sub-agent. This record found no material specifying the exact resource or action target the authorization decision evaluates, and does not invent one.

Explicit limits. A Zero Standing Privilege model minting access only for the instant an action needs it, with administrator configured policy distinguishing agent types and setting differing levels of monitoring and step up verification. This record credits the no standing privilege claim precisely as stated and does not extend it to a documented monetary, argument or use count limit, none of which this record found named.

Inherited assumptions. Continuous Identity's own framing directly targets the assumption this record has named since its earliest coverage: that an agent's identity alone, once established, is treated as sufficient authority for whatever action it next attempts. A SPIFFE based identity is real, cryptographically verifiable evidence of which agent is acting; it is a different claim from evidence that the action itself was authorized, and CrowdStrike's own real time, per action evaluation is built to supply the second decision the first does not. This record credits that as the strongest action level authorization claim in its own current CrowdStrike material, while noting it could not independently verify the policy engine's own decision logic beyond CrowdStrike's account of it.

Revocation or modification. Documented as dynamic: CrowdStrike's own material states access is granted, denied and revoked based on real time risk. This record found no stated propagation latency, meaning how quickly a revoked grant actually stops an agent process already mid action, and does not assume instantaneous propagation absent a specific claim that it is.

Challenge authority. Step up verification is named as a configurable policy option distinguishing agent types. This record found no specification of whether a step up event presents a challenge to a human, requires an approval, or triggers a further automated check without human involvement, and states the mechanism as unknown rather than assuming a human in the loop model from the term alone.

Recovery. Undocumented. Revocation stops further use of an access grant; nothing this record could reach describes reversing an effect an agent action already completed before that revocation occurred.

Provenance evidence quality. High for the product's existence, its 15 June 2026 unveiling at Identiverse 2026, its SPIFFE based identity claim, its SGNL acquisition basis, and its owner, caller and device risk evaluation model, corroborated across repeated, independently phrased search passes converging on consistent wording. Partial for the exact policy engine mechanics, the precise action and resource model evaluated, and step up verification's own binding mechanism. Partial, added 7 September 2026, for SSF: named alongside SPIFFE as one of the modern identity standards behind real time authorization, with SSF's own specific technical function inside that decision, as opposed to CrowdStrike's separately stated work helping advance SSF industry wide, undocumented beyond that naming. Unknown for grantor legitimacy, for revocation propagation latency, and for any independent security evaluation, since www.crowdstrike.com was blocked to direct fetch in this session's tooling environment, and this record found no independent technical documentation or third party assessment beyond search convergence corroborating CrowdStrike's own material. An editor with unblocked access to CrowdStrike's own Continuous Identity documentation should confirm the mechanics above directly before any claim in this section is relied on beyond the manual review level recorded here.

A claimed CrowdStrike and OpenAI Codex extension of Falcon Guardian: what this verification pass checked and did not find

The brief behind this update named a specific qualifying development: that on 2 September 2026, CrowdStrike and OpenAI announced an expanded partnership explicitly extending Falcon Guardian's runtime controls to supported Codex agents, with CrowdStrike stated to say, for those Codex agents specifically, that Guardian can discover them, identify who deployed them and what they access, connect their activity to Falcon telemetry, detect compromised or unauthorized behavior, define which supported Codex actions are permitted, and translate that governance policy into enforceable runtime controls. This record treats that as a claim to verify, not as an established fact to write up, the same discipline it applies to every other development in this piece.

Direct fetch of ir.crowdstrike.com and www.crowdstrike.com, the domains carrying the cited press release, blog post and product page, was blocked by this session's network egress proxy on every attempt, the same session wide restriction already stated for Guardian's own 1 September 2026 material above. This record's own method for that material, when direct fetch is blocked, is repeated, independently phrased web search passes; where those passes converge consistently on the same wording, as they did for Guardian's three named capabilities, for Continuous Identity's SPIFFE based identity claim, and for Reco's Browser Guard, this record credits the claim at a manual review evidence level and states it as such. That method found no equivalent convergence here. More than a dozen independently phrased search passes, run across a full working session, including searches for the claimed release title and URL directly, for exact phrases drawn from the claimed capabilities such as a Codex agent discovery, identification and telemetry chain, and for the underlying partnership more generally, returned CrowdStrike's own well corroborated 1 September 2026 material, already covered above, its separate and materially different Falcon Shield product, which discovers GPTs and Codex agents created inside OpenAI's ChatGPT Enterprise and dates to an August 2025 Black Hat announcement rather than to this radar window, and OpenAI's own Daybreak initiative, in which CrowdStrike is named as a defense side partner rather than as a party extending its own endpoint product to Codex. No search pass surfaced the claimed press release itself, its title, or any independent report describing a Codex specific extension of Falcon Guardian.

This record does not conclude from that absence that the claimed CrowdStrike and OpenAI announcement is false; a session wide network restriction that blocks every crowdstrike.com and ir.crowdstrike.com fetch is exactly the condition under which a real but not yet widely indexed release would also fail to surface through search. What this record states is narrower and, for its own purposes, sufficient: this verification pass could not independently corroborate the claim by either method available to it, in clear contrast to the same session corroborating Guardian's own 1 September 2026 capabilities, Continuous Identity's capabilities, and Browser Guard's capabilities each within a small number of passes. Because of that, this record does not add a Codex specific extension of Falcon Guardian's Agent Access Controls, Agent Runtime Visibility or Runtime Detection and Response to the material verified above, does not attribute a Codex specific discovery, telemetry or containment claim to CrowdStrike, and does not treat Falcon Shield's separate, 2025 dated Codex governance claim, confirmed above as a different SaaS layer product from Guardian, as evidence for an endpoint layer Codex claim it does not itself make.

One further distinction holds regardless of whether a future editor confirms the claimed announcement. This record's own reading of Guardian's Agent Access Controls, above, already states that CrowdStrike's own material describes an agent type level run or block decision, coarser than and distinct from authorizing one specific downstream action a permitted agent then attempts. A claim that Guardian can "define which supported agent actions are permitted" for Codex specifically would need to state, with the same precision, whether that decision binds a tool, a command, a file operation, a specific argument or destination, or a broader agent type and behavior category, before this record would read it as action level authorization rather than as the same coarser, agent type gate Guardian's own material already documents. This record does not resolve that question in either direction here, because it could not confirm the underlying claim to begin with, and states it as the specific test a confirmed version of this claim would still need to pass.

Update, 3 September 2026: the Codex extension, now corroborated, and CrowdStrike's Agentic IdP

A further verification pass, run on 3 September 2026 using additional independently phrased search queries beyond the more than a dozen recorded in the section above, found what the earlier pass did not: consistent corroboration, across CrowdStrike's own investor relations mirror and independent trade coverage, of a CrowdStrike and OpenAI announcement dated 2 September 2026 describing an expanded partnership that extends Falcon Guardian to supported OpenAI Codex agents and separately brings OpenAI's GPT-5.6 Cyber model into the Falcon platform for CrowdStrike's own Frontier AI Readiness and Resilience service. This record corrects its earlier finding rather than silently revising it: the 2 September 2026 announcement is real, and this record's prior inability to corroborate it reflected a session wide network restriction and an earlier round of search queries that had not yet surfaced it, not evidence the announcement did not exist. What remains true from the earlier pass is narrower and still holds: this record found no material, in this newest pass either, stating with the same precision the earlier section already asked for, whether Guardian's Codex specific action decision binds a tool, a command, a file operation, a specific argument or destination, or the same coarser agent type and behavior category Guardian's own material already documents elsewhere in this record, and this record does not resolve that question now for the same reason it did not resolve it before, because CrowdStrike's own material, blocked to direct fetch throughout, does not state it at that level of precision in anything this record could reach.

The same verification pass also confirmed a separate, more consequential CrowdStrike development named in the same radar window: CrowdStrike introduced the CrowdStrike Agentic Identity Provider, Agentic IdP, on 2 September 2026 at Fal.Con 2026, an upstream registration and identity provenance layer CrowdStrike's own material states fills a documented gap in Continuous Identity for AI Agents. CrowdStrike's own material states Falcon Guardian discovers agents and Agentic IdP registers each one, the moment it comes online, into a single authoritative directory, issuing a cryptographically verifiable identity CrowdStrike says cannot be spoofed or shared, and that only a trusted, registered identity is eligible for the downstream authorization decision Continuous Identity already makes. This record does not add Agentic IdP's own ledger here, to avoid duplicating evidence this corpus already carries once: Moona Intelligence's own coverage of Google Cloud's Agent Identity and Auth Manager verifies Agentic IdP in full, against the same nine dimension Authority Provenance ledger this record already applies to Continuous Identity and Falcon Guardian above, and reads it as a second, independently reached instance of the same identity primitive versus credential broker split Google's own architecture already draws. This record's own Continuous Identity and Falcon Guardian ledgers above are unchanged by Agentic IdP's own introduction; Agentic IdP is the registration and identity layer upstream of both, not a restatement of either.

Where this sits against Moona's own coverage

Okta's Cross App Access answers an adjacent but distinct question: whether an AI agent may stand in for an employee's own identity to reach a connected cloud application at all, resolved through an administrator's policy at an enterprise identity provider, with the resource application's own authorization server independently issuing the token actually used. That architecture governs a connection between two applications and, on the evidence Moona Intelligence's own review of it found, does not evaluate a specific file, program or local system resource an agent touches once running. Somansa's reported claim sits at a different point entirely: a local endpoint, no identity provider in the loop, no OAuth exchange, governing what an agent process may do to files, programs and system resources on the machine it actually runs on. Moona's own coverage of execution time authority controls across cloud hosted agent runtimes, Google's Agent Gateway, Microsoft's Azure SRE Agent, Cloudflare's WriteGuard and others, verifies a related but also distinct claim: that a proposed tool call can be evaluated against policy immediately before it reaches a cloud hosted service, independent of whatever identity permission the agent already holds. None of those mechanisms has anything to inspect at the moment a local agent process opens a file on an employee's own laptop, because that action can complete before any of them are ever engaged. This record's distinct contribution is narrower than any of those three, and specific to the layer none of them reaches: a human employee's own operating system account access does not have to become the full authority envelope of every AI agent process that happens to run under that account, and Somansa is reported evidence, not yet independently confirmed at the mechanism level, that at least one vendor is building a policy layer at the endpoint itself to enforce that separation, validated so far through proof of concept deployments in large enterprise environments rather than demonstrated broad production adoption, with a next generation version planned for the fourth quarter of 2026 that this record treats as the same product lineage rather than as a second, independent development. Reco's Browser Guard, verified above, occupies a fourth and separate layer again: a browser session already authenticated to a destination, reachable to an employee through their own corporate or personal account, is not the same fact as the AI assistant, copilot, coding agent or autonomous workflow acting through that session being authorized to use it, and Browser Guard is evidence that at least one vendor is inserting a policy decision into the managed browser path itself, upstream of any endpoint process check, cloud identity exchange or execution time tool call gateway this record has already verified, and confined, on its own privacy policy's evidence, to that managed Chrome extension path rather than to every route by which an agent can reach the same destination. CrowdStrike's Falcon Guardian, verified above, does not add a fifth layer; it reinforces the first one, with a major incumbent endpoint security vendor's own independent evidence that an employee's own account being permitted to run software on a managed Windows or macOS machine is not the same fact as a given AI agent process being permitted to run under that account at all, discovered, causally traced and access controlled at the endpoint rather than merely logged. CrowdStrike's own Continuous Identity for AI Agents, verified separately above and kept apart from Guardian because nothing this record could reach documents the two as one integrated decision, answers a different and complementary question at a different point: not whether an agent may run on a device, but whether one specific action that agent then attempts should be authorized in real time, evaluated through a SPIFFE based identity, the calling and owning parties, and device risk. This record does not conclude from any of this that the endpoint is the correct or only place to enforce Agent Authority; it now has independent evidence of active enforcement attempts at the endpoint, the browser and the cloud identity and execution time layers, from vendors that do not appear to be coordinating with each other, and reads that convergence as evidence the underlying question is real and unresolved across the market, not as a verdict that any one boundary has won.