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.

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.