By Daks J
AI agents should receive only the access needed for a specific job, and that access should be checked again before each consequential action. For a business workflow, define which records the agent can read, which changes it can make, when a person must approve, and what happens if the task or risk changes halfway through.
Microsoft's October 19, 2026 post, “Securing the agentic insider,” makes continuous oversight of internal agents its central concern. The practical question for an implementation team is concrete: if an agent becomes unsafe after its first successful step, can the application remove its authority before the next step causes damage?
What Microsoft announced, and what still needs checking
In its accompanying technical announcement, Microsoft introduced Dynamic Permissions, Dynamic Agent Risk, and Dynamic Conditional Access for agents. The described approach ties authority to the current task and adjusts it as risk changes, including restricting writes while preserving appropriate reads.
Treat this as an announcement, not confirmation that every capability is generally available in every tenant. The post does not establish a universal rollout date or complete licensing requirements for the new dynamic controls.
There is a second distinction to check. Microsoft's Defender support matrix separates agent discovery from runtime protection. It labels Windows runtime protection as preview and says protection must be configured. Its network inspection does not cover certificate-pinned connections or HTTP/3. A discovered agent is therefore not automatically a protected agent.
Before buying or deploying, verify the exact agent, operating system, inspection method, configuration, license, and release status. The design below is a proposed application architecture, not a claim that one Microsoft switch implements the entire workflow.
A concrete workflow: prepare a support response without taking over the account
Consider a support team handling product-service questions. An agent could assemble the relevant ticket history, retrieve the applicable service policy, and prepare a response for a support specialist. The business benefit would be less time spent gathering context.
This is an illustrative pilot, not a Hexagon customer story or a report of measured results.
Give the agent one ticket at a time. It may read that ticket, a small set of related order fields, and the approved knowledge-base articles. It may prepare a private draft. In a later stage, it may add a clearly labeled internal note through a dedicated connector.
Keep customer messages, refunds, account changes, and ticket closure outside that initial authority. A service question can quickly become a promise about compensation or a change to a customer's account. Those actions deserve separate rules even when they appear in the same conversation.
The starting deliverable is a response proposal with its supporting records and unresolved questions. Success means making the specialist's work easier without quietly expanding what the agent controls.
Write a permission contract before connecting tools
A useful permission contract is an enforceable description of the job. The process owner and integration engineer should agree on at least these fields:
- Owner and purpose: the support manager responsible for the workflow and the specific result requested.
- Record boundary: the ticket identifier, customer identifier, and approved related order identifiers, resolved by trusted application logic.
- Readable data: ticket messages, product identifier, order status, service entitlement, and current policy references. Exclude payment credentials, unrelated customers, and unnecessary personal details.
- Allowed operations: retrieve those fields and save a private proposal. If internal notes are enabled, allow only the dedicated note operation on the assigned ticket.
- Approval boundary: external sending, refunds, account edits, and closure require their own authorized path.
- Expiration and stop conditions: access ends when the task finishes, is cancelled, expires, or loses its valid business context.
Do not let the model supply its own customer scope. If it asks to fetch a different account, the connector should compare the request with the stored task boundary and reject it. A ticket message containing another customer's identifier is not permission to retrieve that customer's information.
OWASP's excessive-agency guidance recommends narrow tools, minimum downstream permissions, and authorization outside the language model. Apply that principle to each operation rather than handing the agent a general-purpose administrator connection.
Put enforcement where the business action happens
The implementation needs more than a careful prompt. Use a task record, a policy decision, and a connector that enforces that decision:
- Create the task from an authenticated request. Record the requester, assigned ticket, purpose, permitted operations, expiration, and policy version. Validate the requester's own access before delegating anything.
- Resolve data through restricted adapters. Connect the help desk, CRM or order system, and knowledge base using stable identifiers. Retrieve only permitted fields. Preserve source timestamps and the version of the service policy.
- Check every attempted operation. Before a connector reads or changes a record, check the task's current state, target, operation, and authorization. Do not rely solely on a decision made when the session started.
- Keep credentials outside the model. The connector performs the authorized operation. The model receives the relevant result, not a reusable credential that can unlock another route.
- Return evidence with the proposal. The reviewer should see the source ticket, relevant order facts, policy reference, and missing information alongside the draft.
If an existing SaaS connector exposes broad access, a tool description saying “use only this ticket” does not narrow the underlying permission. Add a constrained service layer, choose a more limited integration, or keep that system out of the pilot.
These are API integration decisions: how identities map across systems, where authorization runs, how records stay current, and which component owns a failed request.
Decide what happens when risk changes mid-task
Suppose an incoming ticket includes instructions to export the customer list to an outside address. That text is customer-supplied content to assess, not authority to change the agent's assignment.
For this pilot, define specific responses:
- An out-of-scope record request: deny the request and record the attempted target. Repeated or suspicious attempts should pause the task for investigation.
- A suspicious instruction or unexpected tool sequence: freeze business writes and route the evidence to an authorized reviewer. Preserve reads only where the policy explicitly says they remain safe.
- A changed ticket assignment or expired task: deny further access until the application establishes a new, valid scope.
- Evidence of compromised credentials or uncontrolled data access: stop execution and invoke the organization's incident process rather than continuing in a nominally read-only mode.
The important behavior is observable at the connector. Changing a label from “low risk” to “high risk” is not containment unless the next prohibited request actually fails.
Test timing as well. If a write was already accepted by a downstream system when access was withdrawn, revocation cannot undo it. Reconcile the request identifier and destination state before retrying or compensating. Report an uncertain outcome as uncertain.
Make human approval specific enough to enforce
When the workflow later supports customer replies, show the reviewer the exact recipient, message, ticket, and business consequences. Approval should apply to that version of that action, with a defined expiration.
If the recipient, wording, compensation promise, or relevant record changes, require another review. A general “looks good” on an earlier draft should not authorize a different message.
The sending service should verify the approval record immediately before transmission and prevent a duplicate send. The agent should not be able to create its own approval or replace the approved content after review.
Keep this control usable. If reviewers receive frequent low-value prompts, they will have less attention for consequential decisions. Automate bounded preparation, present a concise change preview, and reserve approval for the business actions the organization has chosen to retain.
Test the permissions, then measure the work
Start with synthetic or properly approved test tickets. Build expected outcomes before running the agent. Include ordinary service questions, a wrong-customer identifier, conflicting policy versions, an expired task, an attempted refund, and an instruction to send data outside the approved workflow.
Run a dedicated deny-write test: allow the agent to prepare its response, then withdraw note-writing permission before it calls the note connector. Verify in the destination system that no note was created. Also test a valid note so a broken connector cannot pass simply by refusing everything.
Record two separate groups of measures:
- Business usefulness: median preparation time, specialist correction time, percentage of proposals accepted without material changes, unresolved-case rate, and total cost per accepted proposal.
- Control effectiveness: out-of-scope attempts blocked, unexpected writes, unapproved external sends, time from revocation to enforcement, and completeness of action records.
Compare the pilot with the team's existing process on comparable cases. Include review, monitoring, integration support, and exception handling in the cost, not just model usage.
Set expansion criteria in advance. Every defined authorization test should pass, each consequential action should have a traceable decision, and the workflow should show a useful improvement against the baseline. These are proposed acceptance criteria, not evidence of zero risk or a promised productivity gain.
Know the limits before adding autonomy
Task-scoped permissions cannot make a wrong answer correct. The agent may still misunderstand a warranty, use an outdated article, or omit an important fact inside its permitted data.
Risk detection can also miss a malicious instruction or flag legitimate work. Hard restrictions should remain effective even when no alert fires. Do not require access to a model's private reasoning as a prerequisite for enforcing a record boundary or blocking a refund.
Read-only access deserves scrutiny too. Data can leak through generated responses, logs, or approved-looking destinations. Minimize what reaches the model, restrict where results go, and protect the audit trail. Log identifiers, decisions, policy versions, and necessary evidence without collecting reusable secrets or unrelated customer content.
Assign someone to review failures and permission changes. An agent's task may be temporary; ownership of its integration, monitoring, and support is ongoing.
Frequently asked questions
They are permissions tied to a defined job, such as preparing a response for one support ticket. They specify the records, operations, duration, and approval conditions for that task rather than giving the agent all of an employee's standing access.
Sometimes. The application can allow explicitly safe reads while denying changes. But read access can still expose information, so suspected compromise or an invalid task may require stopping both. The response should follow the actual risk and a predefined policy.
The October 19 announcement does not establish blanket availability. Confirm the capabilities and licensing for your environment. Microsoft's separate Defender matrix lists Windows runtime protection as preview and distinguishes it from discovery.
Prove that the connector enforces the approved scope, rejects forbidden actions, handles revoked access, prevents duplicates, and preserves a useful audit record. Then evaluate whether the proposed write is sufficiently bounded and recoverable to delegate. Passing a pilot does not authorize every future action.
Start with one permission boundary you can prove
Choose a workflow where the team can explain both the expected benefit and the actions it is unwilling to delegate. Build the permission contract, connect the minimum data, test allowed and denied operations, and measure the result before expanding scope. Hexagon's business automation services cover workflow rules, approvals, integrations, and monitoring.
