Security Boundaries for Agents That Can Take Real Actions
An agent that can answer questions is an information system. An agent that can send messages, update records, initiate workflows, execute code, call business APIs, or change access is also an actor. That shift changes the security problem. The architecture must control not only what information the model can see, but also what identity it uses, which tools it may invoke, which actions those tools expose, and how the organization prevents a manipulated input from becoming an authorized business action.
The current AB-100 role emphasizes secure, scalable cross-platform AI solutions and the end-to-end deployment of agentic systems. Security therefore cannot be added as a content filter after the prompts work. It must define the trust boundaries around data, agent identity, connectors, tool permissions, network paths, memory, approvals, and action logging.
For an Agentic AI Business Solutions Architect, the key principle is simple: the agent should receive no more authority than the business task requires. The complexity comes from enforcing that principle when the system spans users, agents, applications, models, and external tools.
Give the agent its own identity where the architecture supports it
Shared credentials make attribution and revocation difficult. Modern agent platforms increasingly support dedicated Microsoft Entra identities for agents, allowing administrators to reason about the agent as a workload principal rather than as a hidden extension of a developer account. Dedicated identity creates a place to apply permissions, review activity, and revoke access without affecting unrelated services.
The broader identity and access management rule still applies: strong authentication does not justify broad authorization. An agent identity with excessive application permissions is still dangerous even if no password or client secret is exposed.
Separate user authority from agent authority
Some actions should occur in the user’s security context so the agent cannot exceed what that person could do directly. Other background processes need an autonomous workload identity with narrowly scoped permissions. The architecture should decide explicitly which model applies to each action instead of allowing connectors or service accounts to choose by convenience.
On-behalf-of access can preserve user authorization, but it also requires careful token and consent design. Agent-owned access can enable automation after the user leaves the conversation, but it creates independent authority that must be governed. Mixing the two without clear audit semantics makes it difficult to answer the most important incident question: who, exactly, authorized this action?
Constrain tools before trying to constrain language
Prompt instructions such as “never delete customer records” are useful behavioral guidance, but they are not a substitute for authorization. If the agent never needs deletion, the tool or API scope should not expose deletion. If it needs to update only a narrow field, the integration should avoid giving broad write access when a narrower operation can be designed.
This is the practical meaning of least privilege for agents. Model behavior can be probabilistic and adversarial inputs can attempt to redirect it. Tool permissions provide a harder boundary. When a prompt injection succeeds in changing the model’s intention, a constrained tool layer can still prevent the action from exceeding the system’s authorized capability.
Treat connectors and tools as part of the attack surface
Every connector expands what the agent can reach. A calendar connector, CRM connector, file store, browser tool, code interpreter, or custom API brings its own authentication, data exposure, input validation, and failure behavior. Architects should inventory tools the same way they inventory external integrations in a conventional application.
For each tool, document the operations available, identity used, data returned, outbound destinations, rate limits, and audit evidence. Broad connector enablement because “the agent might need it later” creates latent privilege. Security improves when unused tools are removed and production environments expose only the operations required by the approved business scenario.
Design for prompt injection as a boundary-crossing attempt
An agent may consume untrusted content from email, web pages, documents, tickets, or user messages. That content can contain instructions intended to manipulate the model into revealing data or calling a tool. The architecture should assume that retrieved content can be hostile and separate data from authority: information from a document should not gain the power to redefine system policy.
Content filtering and model safeguards help, but the strongest protection is defense in depth. Limit tools, validate parameters, require approval for consequential actions, restrict data access, isolate sensitive workflows, and log action intent. A successful prompt injection should encounter additional controls before it can become a damaging transaction.
Protect secrets and avoid passing credentials through prompts
Agents often need access to APIs, databases, and services, which can tempt teams to place keys or tokens in prompts, environment text, or tool instructions. Those values can leak through logs, debugging, memory, or model context. Prefer managed identity, federated identity, secure connection objects, and secret stores so credentials remain outside the conversational context.
Where secrets are unavoidable, ownership and rotation must be defined. The agent should not know more credential material than the runtime needs. This is a direct extension of established data privacy and compliance thinking: minimize sensitive material, control access, and retain evidence of how it is used.
Use human approval for high-impact action classes
Human oversight is not a substitute for technical security, but it can be an important authorization boundary. The architecture can require approval before an agent changes payment details, sends an external communication, modifies privileged access, deletes records, or performs another action whose consequence exceeds the agent’s normal risk tier.
The approval step should show the proposed action and its evidence, not merely a generated summary. Reviewers need enough context to catch an unexpected target, unusual amount, risky permission, or missing prerequisite. Approval events should be logged as part of the same transaction so later investigation can reconstruct both machine and human decisions.
Segment environments and network paths
Development agents often have experimental tools and changing prompts. Production agents should operate in environments with stricter data policies, identities, network access, and release controls. Separating development, test, and production prevents a prototype connector or debugging permission from quietly becoming production authority.
Network isolation may also matter for sensitive workloads. Microsoft Foundry supports enterprise controls such as private networking for supported agent patterns, while Power Platform and Copilot Studio provide their own environment and connector governance. The architecture should choose controls that match the data and action risk instead of assuming public endpoints are acceptable because the model service itself is trusted.
Security monitoring must go beyond chat transcripts. Operators need records of tool calls, parameters, downstream responses, agent identity, end-user context, approvals, and resulting business changes. When an agent acts incorrectly, containment depends on knowing which resources and transactions were affected.
Correlated logs also support anomaly detection. An agent that suddenly invokes a rarely used tool, accesses an unusual volume of records, or acts outside its normal time or process pattern deserves investigation. Security teams should be able to disable the agent or remove a permission while preserving evidence for root-cause analysis.
Memory deserves its own boundary. Persistent agent memory can improve continuity, but it can also preserve sensitive data, stale assumptions, or malicious instructions across sessions. Architects should decide what may be remembered, for how long, at what scope, and how a user or administrator can inspect or delete it. Memory should not become an ungoverned side database.
Agent-to-agent communication introduces another trust boundary. A specialist agent should not automatically trust a request merely because it came from another agent. Authenticate the caller, authorize the requested operation, validate inputs, and constrain what context is forwarded. In multi-agent systems, internal traffic can be just as consequential as calls from an external user.
Security testing should include abuse cases, not only expected workflows. Test prompt injection, malformed tool parameters, attempts to cross data boundaries, repeated actions, privilege escalation, unavailable dependencies, and malicious content in grounding sources. A system that performs well on ordinary prompts can still be unsafe when the user’s objective is to make it violate its own operating contract.
Rate and spend limits are security controls too. A compromised or looping agent that cannot exfiltrate data may still create denial-of-wallet costs, overload downstream APIs, or flood a business queue with valid-looking actions. Set quotas, concurrency limits, retry budgets, and anomaly thresholds that reflect the process. Those controls should fail safely and alert operators rather than silently allowing an autonomous component to consume unlimited resources because every individual call was technically authorized.
Third-party tools and external agents should be treated as separate security domains even when integration is technically seamless. Review their data-handling terms, authentication model, logging, availability, and permission scope before allowing an internal agent to delegate work. A trusted internal orchestrator can still create exposure if it forwards sensitive context to a service that follows different retention or governance rules.
Security architecture should make unsafe behavior difficult
The strongest agent security design does not depend on the model making the right choice every time. It gives the model a constrained set of legitimate choices. Dedicated identity, scoped tools, explicit authorization, protected secrets, trusted data boundaries, approval for high-impact actions, environment separation, and complete audit trails reduce the damage any single reasoning failure can cause.
That is a more durable security posture than adding ever longer instructions to the prompt. Agentic systems create new ways for software to decide and act, but the core control principle remains familiar: minimize authority, verify context, separate duties, and preserve evidence. Architecture turns those principles into boundaries the agent cannot simply reason its way around.