CYBERSECURITY TECHNOLOGY AND INNOVATION

Securing AI Agents in Business: Identity, Tool Permissions, Data Boundaries, and Monitoring

Contact OC Security AuditMeet Ali Hassani, CISO

Enterprise AI agent operating through separate identity, tool, data, approval, and monitoring gates inside a realistic automated business environment
Intelligence CenterCybersecurity Technology and InnovationLast fact-checked July 2026Analysis by Ali Hassani, CISO

An AI assistant that only drafts text presents a different risk from an agent that can read email, query customer records, create tickets, change cloud resources, issue refunds, or send messages. Once an AI system can choose and invoke tools, its effective authority is the combination of its identity, permissions, connected data, available actions, network paths, and approval rules.

The security objective is not to make an agent “trusted” in the abstract. It is to define exactly what the agent may do, establish evidence for every material action, limit reachable impact, and make revocation reliable. This article translates current NIST work and Microsoft identity documentation into a platform-neutral control model for business deployments.

Executive summary

NIST’s May 2026 analysis of responses on AI-agent security states that agents present novel risks while many fundamental security practices remain relevant and need adaptation. NIST’s separate work on post-deployment AI monitoring describes the monitoring landscape as important but fragmented. Neither document is a product certification or a complete prescriptive standard.

For a business, the minimum defensible control model is:

  1. inventory every agent, owner, purpose, environment, and connected system;
  2. give the agent a distinct lifecycle-managed identity rather than a shared human account;
  3. grant only the permissions and tools required for the approved workflow;
  4. separate read, propose, approve, and execute authority;
  5. restrict data by purpose, sensitivity, tenant, customer, and retention need;
  6. treat retrieved content and tool output as untrusted input;
  7. log the identity, instruction, tool call, target, decision, result, and human approval;
  8. test disablement, token invalidation, credential rotation, and workflow rollback;
  9. review the agent again whenever its model, tools, data, owner, or deployment changes.

Start with an authority map, not a feature list

An agent’s vendor name or model version does not describe its business risk. Two deployments of the same model may have radically different impact. One can summarize public documentation; another can read private contracts and initiate transactions.

Build an authority map for each production or pilot agent:

Control dimension Questions to document Evidence to retain
Purpose What outcome is approved? What is explicitly prohibited? Use-case approval, owner, risk decision
Identity Is the agent distinct from users and other agents? Who sponsors it? Identity record, owner, lifecycle dates
Permissions Which roles, scopes, records, and tenants are reachable? Effective-permission export and approval
Tools Which APIs, plug-ins, scripts, browsers, and automations can it invoke? Allowlist, version, owner, test record
Data What can enter prompts, memory, retrieval, logs, and outputs? Data-flow map, classification, retention rule
Actions What can the agent read, propose, create, modify, send, delete, or pay? Action matrix and approval thresholds
Network Which destinations and protocols are allowed? Egress policy, proxy and DNS evidence
Monitoring Can investigators reconstruct an action end to end? Audit logs, correlation identifiers, alerts
Recovery Can the agent be disabled and its effects reversed? Tested kill switch, token revocation, rollback

The map should describe effective authority, not only direct permissions. An agent may reach a sensitive outcome indirectly through a ticketing system, automation platform, service account, delegated user, or downstream application.

Give every agent a distinct identity and accountable owner

Do not run a production agent under an employee’s normal account or a shared service credential. A distinct identity makes scope, monitoring, access review, expiration, and incident response possible. Record a business owner, technical owner, security reviewer, and—where the platform supports it—an ongoing sponsor responsible for recertification.

Microsoft’s current Entra Agent ID documentation illustrates this direction with dedicated agent identities, blueprints, sponsors, lifecycle governance, and monitoring. These are Microsoft-specific capabilities, not universal requirements. The underlying principle is platform neutral: the identity should be recognizable as an agent, attributable to an approved purpose, and removable without disrupting a human user.

Use short-lived credentials, managed identities, or workload-identity mechanisms where possible. Avoid embedded API keys and long-lived shared secrets. Store credentials outside prompts, source code, and retrievable document stores. The agent should receive a narrowly scoped capability at execution time rather than carrying standing authority for every possible task.

Separate delegated and autonomous authority

An agent acting on behalf of a user should normally be limited by that user’s rights and the approved task. An autonomous service agent may need application-level permission, but tenant-wide access should be exceptional, documented, and reviewed.

Microsoft’s authorization guidance for Agent ID distinguishes delegated and application permissions and blocks some high-risk directory capabilities for agent identities. Even where a different platform does not impose those safeguards, organizations can adopt the same design intent:

  • prefer task-specific delegated access when the action belongs to one user;
  • use application permission only when the business process genuinely spans users or resources;
  • separate read from write authority;
  • scope by resource, tenant, region, environment, or record set;
  • time-limit elevated permission;
  • require a new review when the requested scope expands.
Physical logistics and cloud operations workflow showing a bounded AI agent reaching only approved systems while high-impact actions wait at a human authorization gate
A production agent should reach only approved tools and data, while consequential actions pause at an independent authorization gate and every step remains reconstructable.

Allowlist tools and constrain parameters

The tool layer is where a language model becomes operational. A seemingly safe agent can become high impact when connected to a shell, browser, email sender, payment API, identity directory, cloud control plane, or automation service.

Maintain a tool registry with owner, version, authentication method, allowed operations, data types, destinations, rate limits, and shutdown procedure. Deny unreviewed tools by default. Validate parameters outside the model: permitted recipient domains, maximum transaction amount, approved resource groups, allowed file types, and query limits should be enforced by deterministic controls.

Do not rely on a prompt that says “never delete production data.” The tool or authorization layer should make that action unavailable, require a separate approval, or restrict it to a recovery-tested process.

Put protected data boundaries around prompts, retrieval, memory, and logs

An AI data-flow review should cover more than the initial prompt. Information may enter through uploaded files, retrieved documents, browser pages, emails, connectors, tool results, conversation memory, evaluation datasets, debugging traces, and vendor telemetry. It may leave through responses, actions, logs, plug-ins, or downstream systems.

For each flow, determine:

  • whether the data is permitted for the use case;
  • whether personal, regulated, contractual, privileged, or confidential information is present;
  • whether the provider uses inputs or outputs for service improvement;
  • where processing and storage occur;
  • how long prompts, responses, memory, and logs remain;
  • who can retrieve them;
  • whether deletion and legal-hold obligations can be met;
  • whether the agent can combine data across customers, departments, or tenants.

Use redaction, tokenization, data minimization, retrieval filters, separate indexes, tenant isolation, and output controls based on the actual risk. “The model does not train on our data” is not a complete answer to storage, access, subprocessors, logging, breach notification, or deletion.

Treat external content as instructions an agent must not automatically obey

Documents, webpages, messages, tickets, and tool output can contain text that tries to redirect an agent’s behavior. The organization should treat retrieved content as untrusted data, separate it from system instructions where the architecture allows, and test indirect prompt-injection scenarios.

High-impact actions should be based on validated fields and business rules, not free-form text alone. For example, a payment-change agent should compare a vendor identifier and approved bank record through a controlled API; it should not accept new banking instructions from an email body and execute them because the message sounds authoritative.

Design human approval for the actual decision

Human review is useful only when the reviewer sees enough evidence and has time and authority to reject the action. A generic “approve” button beneath an AI-written summary can become automation bias.

For consequential actions, show:

  • the initiating user or event;
  • the agent identity and current version;
  • the target resource or recipient;
  • the exact proposed change or message;
  • the data that will leave the organization;
  • the source records used;
  • policy exceptions and confidence limitations;
  • a clear reject, edit, and escalate path.

Use dual approval or an independent verification channel for payments, privileged access, data exports, production changes, legal notices, and public communications. The approval control should exist outside the agent’s editable context.

Preserve action-level monitoring and evidence

NIST’s 2026 report on monitoring deployed AI systems emphasizes the need for post-deployment monitoring while noting that methods and responsibilities remain fragmented. For security operations, a practical log must connect what the agent was asked to do with what it actually did.

Record, as appropriate:

  • agent and model identifiers and versions;
  • initiating user, service, or event;
  • policy and prompt version;
  • retrieved sources and data classifications;
  • tool name, parameters, target, and correlation ID;
  • permissions and credential type used;
  • approval or denial, reviewer, and timestamp;
  • result, error, retry, and downstream change;
  • network destination and data volume;
  • safety or security control decisions.

Protect logs from the agent’s modification, synchronize time, define retention, and restrict access. Avoid logging unnecessary sensitive data merely to increase observability.

Test failure, compromise, and shutdown

An agent security test should include normal tasks, denied actions, malformed input, prompt injection, excessive data requests, tool failures, stale credentials, unauthorized recipients, cross-tenant access, and attempts to bypass approval.

Exercise the response process:

  1. identify the agent and its current authority;
  2. disable the identity or blueprint;
  3. invalidate tokens and rotate credentials;
  4. stop queued and downstream automations;
  5. preserve prompts, retrieval, tool, identity, and network evidence;
  6. determine which actions completed and which were only proposed;
  7. reverse changes where safe;
  8. notify affected owners and evaluate legal or compliance duties;
  9. re-enable only after the cause and control changes are validated.

Microsoft documents agent sign-in and audit visibility and response options in its agent identity management guidance. Organizations using other platforms should verify equivalent evidence and disablement capabilities before production use.

A 30-day implementation sequence

Week 1: inventory and classify

Find approved, pilot, user-created, embedded, and vendor-managed agents. Record purpose, owner, data, tools, identity, environment, and action level. Stop or isolate agents with no accountable owner or unknown credentials.

Week 2: reduce authority

Replace shared accounts, remove unused scopes, split read and write functions, restrict egress, add tool allowlists, and define explicit action limits. Require approval for consequential changes.

Week 3: make actions observable

Connect agent, identity, application, network, data, and workflow logs. Create alerts for permission changes, new tools, unusual destinations, high-volume access, repeated denied actions, and activity outside the approved schedule or resource scope.

Week 4: test and govern

Run an abuse-case test and a disablement exercise. Present the authority map, findings, residual risk, owner, review date, and go/no-go decision to leadership. Add the agent to change management, access review, incident response, vendor review, and data-governance processes.

An AI security governance review can help establish ownership and evidence. A virtual CISO engagement can connect the technical controls to risk acceptance, policy, vendor decisions, and executive reporting.

Standards and guidance: use the right level of certainty

The NIST AI Risk Management Framework is voluntary and intended to help organizations govern, map, measure, and manage AI risk. NIST’s Cyber AI Profile was still a preliminary draft in the public material reviewed for this article. It should not be presented as a final standard or a certification requirement.

Microsoft product documentation describes controls available in its ecosystem. It is evidence of product design and recommended use, not proof that a particular deployment is secure. Organizations should verify saved configuration, effective permission, actual logs, and tested outcomes.

Questions executives and IT leaders should ask

  • Which agents can take action, and which only provide information?
  • Does every agent have a distinct identity, sponsor, owner, and expiration or review date?
  • What is the agent’s effective authority after downstream tools and automations are included?
  • Which data can enter prompts, memory, retrieval, logs, and outputs?
  • Which actions require approval, and what evidence does the reviewer see?
  • Can security reconstruct one action from instruction through downstream result?
  • Can the organization disable the agent and invalidate its authority within minutes?
  • When was the last abuse-case and recovery test completed?

Sources

Turn an AI pilot into an evidence-based security decision

Before an agent receives production data or authority, contact OC Security Audit to discuss an independent review of identity, cloud, data, vendor, monitoring, and incident controls. Learn more about Ali Hassani, CISO and his experience across cybersecurity, infrastructure, cloud security, audit, and executive risk guidance.

Update and correction history

  • July 2026: Initial analysis prepared from NIST publications and official Microsoft product documentation available through July 2026.