Enterprise AI security protects the data, identities, applications, and operational systems exposed through an organization's use of AI. It connects each path of use to controls, evidence, and an owner able to act on the affected resource.
This operational definition focuses on enterprise use by people and agents. The security assessment follows what can be read, disclosed, changed, or interrupted as work crosses applications and systems. AI governance supplies the broader responsibilities and permitted purposes; security examines the protection of the resources involved and the organization's ability to respond.
Map the enterprise AI attack surface by path of use
Consider a hypothetical initiative to update internal support documentation. Employees use an approved AI application to help draft articles. A browser helper has permission to read selected work pages and send content through another service. An agent uses a service identity to update drafts in an internal knowledge base.
Those are specific conditions of this example, not claims about every browser extension, an observed incident, or a KonaSense integration. The approved application's assessment does not establish the helper's permissions, the destination of its transmissions, or the agent's authority in the knowledge base. Shared business purpose does not make the three paths equivalent.
| Path in the hypothetical initiative | Resource exposed | Control responsibility to assign | Evidence to request |
|---|---|---|---|
| Employee uses the approved application | Material submitted and drafts returned | Application owner with the responsible data owner | Approved handling conditions and the actual submission and sharing path |
| Browser helper reads work pages | Page content available through its granted permissions | Browser or endpoint administrator with the owners of the source data | Installed configuration, permitted access, destination, and observed activity where available |
| Agent updates the knowledge base | Content, write permissions, and affected records | Workflow owner with the destination and service-identity owners | Effective permissions, applicable task scope, and records of attempted and observed changes |
This is a responsibility map for the example, not a complete inventory or coverage score. One person may hold several roles, but each decision needs an identified owner. A resource outside the available observation path remains an investigation or control question, even if another part of the initiative is well understood.
Make human AI usage reviewable in its working context
For employees, the relevant boundary may be copying text, uploading a document, sharing a conversation, or moving generated material into another system. Assess the actual application configuration and workflow. An approved account does not explain whether a particular document, external recipient, or optional client feature was included in the approval.
Give users a permitted route they can recognize: which application and account to use, what material it may receive, and where to send questions or exceptions. The application owner needs a way to review changes to that route, such as a newly enabled sharing feature or a different client. The AI usage governance pillar develops those handling decisions; the security program must connect them to the controls actually available at each boundary.
Investigate Shadow AI and unresolved usage signals
An unfamiliar destination or unreviewed helper should trigger a scoped inquiry: what is installed, what can it access, who uses it, and for what task? In the documentation example, knowing that the approved application is in use does not establish whether the helper's separate path was assessed. Conversely, finding the helper does not prove that sensitive content was transmitted.
Keep unknown status distinct from confirmed unapproved use or a confirmed exposure. Assign someone to resolve the uncertainty using authorized inventory and activity evidence. A missing event can reflect absent collection as well as absent activity. The Shadow AI pillar explains how to turn incomplete signals into a reviewable usage decision without treating every unknown as an incident.
Follow sensitive data beyond the prompt field
Identify which content the workflow can encounter and where copies may persist. In this example, source pages, uploaded material, generated drafts, service responses, and investigation extracts may have different handling needs. A control applied to text entered in one application does not establish protection for a separate helper reading the page or for an agent retrieving data directly.
The data owner should define the permitted purpose and recipients; the owner of each processing or storage point should establish how those conditions are applied. Review access, retention, and references to source content where relevant. Avoid collecting full prompts simply to demonstrate visibility when a narrower record can answer the security question.
NIST's AI RMF Playbook recommends connecting AI governance to existing organizational controls and aligning it with data governance, including sensitive data. That is a useful integration principle, not a product certification or a prescribed architecture for these paths. NIST AI RMF Playbook, Govern 1.2.
Separate an agent's task from its available authority
The knowledge-base agent has a requested outcome and an identity through which it acts. The task might permit updating draft articles while the credential allows changes to published material. The workflow owner and destination owner need to determine whether that difference is acceptable and where it can be constrained. A natural-language task description does not reduce the credential's effective permissions.
Security also needs to consider the material that can influence the agent, including retrieved documents and tool responses. A suspicious instruction, a proposed change, and a completed write establish different facts. The AI agent security pillar examines that threat model in depth. At enterprise level, the necessary handoff is to the people who control the source, runtime, credential, and affected destination.
Include the execution environment of coding agents
Coding agents add a development environment to the assessment: repositories, processes, package scripts, local files, and any permitted remote services. A code review can evaluate a proposed patch without establishing what the agent's earlier processes accessed or changed. Identify the execution identity and environment alongside the repository owner.
If a team introduces a coding agent to maintain the documentation workflow, security should review the actual workspace, runner, credentials, and publication permissions granted to that task. Those are additional conditions to establish, not properties inferred from the agent's name. Coding agent governance explains this delegation and environment review without assuming that every runner or editor has the same authority.
Assess tools and actions at the affected resource
A tool name describes an interface, not the full set of resources its implementation can reach. Identify which service executes the request, which account it uses, what arguments select the target, and what changes the destination can accept. A tool that prepares a draft and one that publishes it may require different authorization even when presented in the same workflow.
Keep the destination's controls in the design. Client policy, human approval, and service authorization have different responsibilities; a client response cannot create a permission the destination has not granted. Where the tool delegates further work, establish how its allowed scope reaches that next component and what remains outside the initial control's view.
Assign owners to governance decisions and their application
A workable assignment separates who defines an allowed use, who configures its control, who can approve an exception, and who verifies the result. In the hypothetical initiative, the data owner may limit content sent to a service, the browser administrator may control a managed helper's availability, and the knowledge-base owner may restrict write access. These are proposed responsibilities, not actions a central dashboard automatically performs.
NIST's AI RMF Playbook calls for documented roles, responsibilities, and communication paths for AI risk management. Use that principle to make the handoff specific enough that a policy question reaches someone empowered to decide and an implementation question reaches someone able to change the control. NIST AI RMF Playbook, Govern 2.1.
For each material control, ask what operation it can affect, what information it uses, and what happens when it is unavailable. The runtime governance pillar explains those contracts. Enterprise coordination does not require one mechanism to perform every role; it requires an honest account of which roles are implemented and which remain unresolved.
Use telemetry and audit evidence to answer a question
Specify the decision the evidence must support. To investigate the helper, the team may need to establish its effective permissions and the actual destination of a transmission. To investigate a knowledge-base change, it may need to distinguish a proposed write, a service request, and the record changed at the destination. One application's activity log will not necessarily answer both questions. The AI observability definition distinguishes model, application, and workflow observations.
Identify the source and limits of each record before correlating them. An agent session can group activity without proving which attempt caused a change, and a policy event can describe a decision without confirming its application. The AI agent audit trail guide develops those distinctions. Access to evidence should remain controlled; copying sensitive material into a broadly accessible alert can create another exposure.
Connect security operations to someone who can act
Observation makes information available. Triage determines its relevance and what needs examination. Investigation establishes the affected data, identity, path, and supported facts. Containment requires an authorized change at a point that can limit the problem. A notification reaching the SOC does not establish that the necessary change occurred.
The incident and governance decision analysis explains why a denied request does not classify the surrounding situation, and how to keep operational restrictions, investigation, and incident declaration distinct.
For the hypothetical helper, an unexplained destination might first require verification by the browser administrator and data owner. If an unauthorized transmission is established, the response must identify which installation, permission, or receiving path can be restricted and by whom. Restricting future transmissions does not prove that previously delivered content was removed. For an unauthorized knowledge-base write, the destination owner may need to restrict the acting identity and assess the changed records. These are conditional response responsibilities, not an incident report or an executed playbook.
Escalate based on the resource and unresolved authority: suspected sensitive-data exposure to the data owner, unexplained execution to the runtime or endpoint owner, and unauthorized changes to the destination and identity owners. Preserve what is known and what remains unverified. Record who accepted the handoff, what action they were authorized to take, and what observation would confirm its effect.
NIST's AI RMF Playbook addresses communicating incidents and errors and following documented tracking, response, and recovery processes. Apply that principle to the organization's existing operations. An integration with an alert queue is a delivery mechanism to verify, not evidence of completed response or a substitute for those responsibilities. NIST AI RMF Playbook, Manage 4.3.
How KonaSense fits into these boundaries
Kona for Browser supports policy evaluation for prompts in compatible AI web applications. Its role is a specific submission boundary. The reviewed browser paths depend on inspection mode and can resume sending when evaluation fails; they do not establish inspection of every extension or outgoing browser request.
For Kona for Agents, the reviewed Claude Code PreToolUse adapter can return a tool-use denial or a request for approval from a policy decision. That implementation falls back to Allow when evaluation fails, and application of the response depends on the host. This is distinct from managing the service identity or controlling every later operation at a remote destination.
The reviewed OTLP trace-ingestion path receives exported activity for background analysis and returns no intervention decision to the emitting application. It can contribute activity evidence within its available context. Assess these mechanisms against the specific paths in use, alongside the enterprise's data, identity, destination, and operational controls.