Three points for today

1. Agent security needs to account for tool calls, secrets, and permission boundaries beyond the chat interface.
2. When RPA and agents work together, connect clearly separated stages for decisions, execution, and audit.
3. A basic MCP deployment review should cover server trust, limited access, logs, and repeatable tests.

1. Agent security: Map what can execute before deployment

For an agent deployment in a Korean enterprise, start by identifying the tools the agent can reach and the data each tool can read, write, or send. Model capability is only part of that assessment. A tool call is an execution request that can change a real system. Searching a file repository, looking up customer information, drafting an approval document, updating a ticket, and sending information outside the organization are different kinds of work. Combining them under one broad permission makes it harder to review each action on its own terms. Operators should maintain a defined inventory of tool names, purposes, input and output formats, required permissions, calling identities, and behavior when a call fails.

This inventory serves more than the security team. Business teams need to know which requests are handled automatically, developers need to know which secrets are used, and operations teams need to know who can stop the process. Secrets require separate management; they should not be mixed into prompts or task descriptions. Passing long-lived credentials with every call, running several automations through a shared account, and leaving test permissions active in production all make it harder to establish who was responsible for an action. Before deployment, remove information the agent does not need to see, grant narrower permissions for each task, and define how credentials expire, rotate, and are revoked.

The 2025 OWASP guide addresses security issues specific to LLM applications. Drawing on that context, this briefing proposes reviewing each tool’s access and handling of secrets before deployment.

Source · OWASPOWASP Top 10 for LLM Applications 2025A guide to security issues in LLM applications.

NIST’s AI Risk Management Framework offers a reference for managing AI risk. The logging, stopping, and recovery items below are proposed operational applications, rather than a uniform checklist mandated by that document.

Source · NISTAI Risk Management FrameworkAn introduction to a framework for managing AI risk.

The ability to audit a system begins with its design, before an incident creates a need to gather logs. At a minimum, connect the request identifier, execution time, calling workflow, selected tool, permission-check result, safe references to relevant inputs, outcome, and any human approval within the same traceable sequence. This does not call for placing raw sensitive content or secrets in logs. Decide what must be excluded, then use identifiers, masking, and access controls where needed to leave a record that supports reconstruction. Operational views should show rejected calls, permission errors, retries, and unusually large batches of actions alongside successful work. Keeping those records usable during routine operations can make an incident easier to investigate.

Incident response needs to extend beyond a button that switches off the agent. Each responsible role should practice stopping a particular tool, immediately revoking a particular credential, canceling or isolating work already in progress, and reversing affected results where that is possible. The response procedure should identify detection signals, the first person responsible for assessment, the contact route to the business owner, the order for withdrawing access, the location for preserving evidence, and the conditions for approving recovery. If the written procedure does not match the actual system, responders may spend the emergency looking for the authority needed to act. Use small, controlled test calls to check that blocking and recovery work, and repeat the same tests after changes.

A checklist should establish a baseline for managing change, with a purpose beyond a single release approval. Apply the same questions whenever a new tool is added, a prompt gains a new business instruction, a data source changes, or responsibility moves to another team. What additional information can this change read? What new actions does it enable? Is the existing approver still the right person? Can the logs distinguish activity before and after the change? Recording the answers helps identify changes that need little review and those that deserve closer attention. Security review then becomes part of design and ongoing operations, with clear reasons for the level of scrutiny each change receives.

2. Coordinating automation: Connect decisions, execution, and audit

RPA, or robotic process automation, and agents can play complementary roles. Repetitive screen entry, structured data transfers, and processing in a fixed sequence may suit RPA when the rules are clear. Agents may be useful for reading documents and proposing classifications, comparing information to suggest a next step, or explaining exceptions. The concern arises when an agent’s suggestion can immediately trigger a wide range of actions. Divide the workflow into decision, execution, and verification stages, and specify the inputs, outputs, and responsible owner for each. Pass the agent’s decision along with its supporting information, allow the execution component to accept only permitted commands, and give the reviewer enough context to compare the outcome with the original request.

Coordinating the workflow means making the rules for moving between stages explicit. Define the conditions for proceeding, the points where a person takes over, and whether a failed task should be retried or stopped. The number of agents involved is secondary. For example, a document classification with low confidence or missing information can go to a review queue before any automatic action takes place. Actions that are difficult to reverse, such as those involving amounts of money, external messages, or changes to customer data, need a separate approval point. These checks may add time to an individual run, but they can help avoid a backlog of unnoticed exceptions that later requires extensive reprocessing. Automatic execution should be reserved for paths the organization can repeat and review reliably.

Anthropic distinguishes workflows that follow predefined paths from agents whose models direct task progression and tool use. That distinction informs the proposal here to connect decision-making and execution while giving each a clear owner.

Source · Anthropic EngineeringBuilding Effective AI AgentsExplains approaches to building workflows and agents.

NIST’s AI Risk Management Framework can inform a review of the risks involved in automation. The approval points and operating measures in this briefing are items to adapt to the work at hand; they do not guarantee a particular cost saving or performance result.

Source · NISTAI Risk Management FrameworkAn introduction to a framework for managing AI risk.

Two practical documents can help operators make this concrete: a workflow diagram and a written set of execution rules. The diagram should include the starting event, data sources, decision stages, automatic actions, human review stages, and possible end states. The execution rules should specify the task’s purpose, input validation, allowed tools, maximum number of actions, time limits, approval conditions, failure handling, and required records. Together, these documents let business teams explain how far the automation goes and help technical teams identify which boundary a change will affect. Without that shared description, even a small modification can disturb hidden dependencies, and gaps in responsibility can remain difficult to spot.

Measurement should also cover more than one result count. Alongside completed tasks, review the share handed to people, retry counts, canceled actions, approval waiting time, reversals, and problems with input quality. These measures are signals for locating delays and failures in the workflow; they do not establish a promised performance target. In a weekly operational review, trace several failures through the actual sequence and distinguish an incorrect decision from an excessive action or an unclear approval rule. The response may involve narrowing permissions, changing an input form, separating an RPA stage, or adjusting a review queue as well as revising a prompt. Effective coordination keeps the business process open to correction instead of treating one model’s judgment as final.

Design exception handling as an expected part of the workflow. Define what happens when inputs are missing or contradictory, an external system responds slowly, a person declines approval, or the same request arrives again. For each case, record whether automation stops, waits, retries within a limit, or hands the work to an owner, and specify the information that accompanies the handoff. A human review screen should show the original request, the inputs used, the proposed action, and the difference between the state before and after execution, alongside the agent’s conclusion. That gives reviewers the business context needed to amend or reject an action. A well-coordinated process needs a controlled way to slow down as well as a fast route through routine work.

3. MCP security and access: Define trust before connecting

When connecting MCP in an enterprise environment, begin by deciding which servers the organization can trust. A familiar server name is not enough to justify access, and carrying a development address directly into production can leave the identity of the connection and its data path unclear. The operational inventory should record each server’s owner, service purpose, address, deployment environment, permitted tools and data, and person responsible for changes. Review a request for a new server together with the business purpose and the minimum functionality needed, and document why any broader access is necessary. An external connection remains a boundary that needs continuing review as the service and its use change.

A user’s successful login does not answer every authorization question. Consider separately which client is accessing which server, what activities it requests permission to perform, and how long that permission remains valid. Keep access as narrow as practical around the business action and the relevant data. Reading and writing, internal search and external transmission, and drafting and final publication should have distinguishable permissions where possible. The permission request or operational procedure should make the requesting party, target server, requested access, expiration, and revocation method understandable. Users should be able to inspect the connections they approved and remove those they no longer need, while operators should be able to review a record of those changes.

The cited MCP document is the June 18, 2025 version and defines authorization for HTTP-based transports. It does not prescribe the same procedure for every MCP connection; it gives separate credential-handling guidance for standard input/output connections. The operational checks below are proposals to adapt to the connection method in use.

Source · Model Context ProtocolAuthorization - Model Context ProtocolThe June 18, 2025 authorization specification for HTTP-based transports.

The OWASP guide provides additional context for reviewing LLM application security. It is neither an MCP-specific certification nor a deployment approval, so the organization still needs to establish server trust and task-specific permissions itself.

Source · OWASPOWASP Top 10 for LLM Applications 2025A guide to security issues in LLM applications.

Logs provide the operational basis for understanding how MCP connections are actually used. Record more than whether a connection succeeded: link the requesting client, selected server, applied permissions, called tool, execution result, rejection reason, and permission changes in time order. Store these records without exposing sensitive values, and restrict access to the logs separately. During regular reviews, look for connections that have gone unused, requests for unexpected access, repeated rejections, and calls outside expected hours. The purpose of this review is to detect whether initially limited access has expanded over time. Closing connections that are no longer used deserves a place in routine operations alongside enabling new capabilities.

Testing is another basic control. For each new combination of server, tool, permission scope, and client, check the paths that should be rejected as well as those expected to succeed. Examine the records and stopping behavior when a call uses expired authorization, requests an action outside its allowed scope, selects an unapproved server, or encounters a network or tool failure. Preserve the results as repeatable cases instead of relying on one person’s recollection. Run those cases again when changes occur after the system enters production. Trust has to be maintained through repeated limits, observation, and testing throughout the life of a connection.

The access-management cycle continues after permission is granted. Revisit connections and their scope when people change roles, projects end, servers move, providers change, or business responsibilities narrow. Ask the owners listed in the connection inventory to confirm their entries regularly, and flag unconfirmed connections for further review. Even an urgent business request should come with an expiration time for temporary access and a named person to review it afterward. That can help prevent an exception from becoming permanent permission by default. Link client and server change records to approvals and test results so that a new owner can explain why a connection exists. These basic controls provide a shared way to keep connections understandable as the organization changes.

Notes for operators

A useful first step today is to list the agents, RPA workflows, and MCP connections already in operation in one table, with their owners and execution permissions. This creates a concrete starting point before drafting a large policy. Mark entries that have no owner, permissions that cannot be explained, and processes whose stopping method is unknown. Then choose one workflow with significant impact and fill in four areas: decisions, execution, audit, and recovery. Give any gaps priority before expanding the functionality. A small review of this kind brings security into everyday operational discussions and gives it a practical place in how the service is run.

A review meeting benefits from one representative each from security, development, business operations, and service operations. Security can examine gaps in permissions and records; developers can assess implementation and the effects of changes; business representatives can explain real exceptions and the cost of reversing work; and service operators can assess whether monitoring and stopping procedures are workable. A process designed from only one perspective may lead others to take unexpected workarounds. The meeting should produce a list of clear next actions: permissions to remove, approvals to add, logs to inspect, failure paths to test, and the next review date. Assign an owner to each action. Maintaining that list can help establish repeatable operating habits that remain useful as individual tools change.

Set priorities according to impact and the difficulty of reversing an action, rather than the novelty of the technology. A simple lookup whose result stays inside the organization can be tested on a small scale. External transmission, bulk changes, commitments to customers, and financial or personnel-related actions deserve narrower permissions and human review at the outset. This distinction considers the cost of an error together with the possibility of recovery. It does not imply that other work is unimportant. Learning how to record actions and route approvals through a small experiment before expanding may reduce the burden of adding those controls later. Start promptly, with work that has a clear and usable path back if something goes wrong.