Identity and Permissions Are Part of Agent Design
Identity and permissions are not deployment details for an AI agent. They determine what the agent can see, which user it represents, which tools it may call, and what the backend will allow when a request becomes an action. The current AB-620 exam includes identity strategy, security, governance, connectors, APIs, and enterprise integration, so authorization is a core design concern across Microsoft certifications covering enterprise AI and application security.
An agent can have excellent instructions and still be unsafe if its permissions are broader than its job. Conversely, an agent with unclear identity can fail legitimate tasks because downstream systems cannot determine whose authority applies.
Separate the user’s identity from the agent’s identity
The user is the human or calling application requesting work. The agent is a software principal with its own platform identity. Depending on the connector and architecture, a downstream call may use the user’s credentials, an agent-related identity, or a maker-provided connection. Those are not interchangeable.
The foundation is classic identity and access management: identify the actor, authenticate it, authorize the requested operation, and keep enough evidence to audit what happened.
Prefer on-behalf-of access for user-specific resources
If an agent reads a user’s mailbox, calendar, files, or records that should follow the user’s own permissions, user authentication or an on-behalf-of model is usually the cleanest boundary. The downstream system continues enforcing permissions it already understands.
This reduces the risk of a shared service credential becoming a bypass around normal access controls. It also makes authorization failures meaningful: if the user cannot access the record directly, the agent should not quietly access it with a more privileged identity.
Use shared agent credentials only for intentionally shared authority
Some actions are truly service-level: query a public catalog, create a standardized support case, or call a low-risk utility API. A shared credential can be appropriate when the business deliberately wants one common identity and the backend permissions are narrow.
Even then, the permission should match the tool. A credential used to create support requests does not need rights to delete requests or administer the system. Ideas from Azure identity and access management remain applicable: minimize scope and separate administrative privilege from operational privilege.
Tool permissions should be narrower than platform permissions
A connector may expose dozens of operations. If the agent needs only two, configure those two rather than granting the entire connector surface when the platform allows granular selection. Smaller capability surfaces are easier for the orchestrator to choose correctly and easier for security teams to review.
Current Microsoft guidance exposes connector-related scopes on agent identities for administrative visibility. That visibility is useful only when the architecture itself is intentional; broad scopes cannot be made safe by documentation alone.
Authorization belongs in the backend as well as the conversation
Agent instructions such as “only managers may approve expenses” are not sufficient enforcement. The tool or backend service should verify that the authenticated principal is allowed to approve that specific expense. Model behavior can guide the conversation, but policy needs a deterministic control.
This is consistent with Microsoft identity administration: authorization decisions should be based on managed identities, roles, groups, policies, and resource permissions rather than informal application assumptions.
Knowledge access needs the same rigor as actions
Read-only access is still access. An agent connected to HR documents, customer cases, legal files, or ServiceNow knowledge can leak sensitive information if the knowledge layer ignores the user’s authorization context. Builders should understand whether a source is globally available to the agent or security-trimmed for each user.
“The agent only answers questions” is not a security exemption. Confidentiality failures can be more damaging than a failed action because they may be difficult to detect afterward.
Anonymous access should be an explicit product decision
Public-facing agents may need anonymous conversations, but anonymous users should reach only capabilities designed for that trust level. Do not expose authenticated enterprise tools merely because the chat channel itself is public. If the conversation crosses into personal or restricted data, introduce authentication at that boundary.
Security fundamentals from security, compliance, and identity remain useful: authentication, authorization, governance, and data protection are distinct controls that must work together.
Identity changes across environments need lifecycle management
Development, test, and production agents may use different connections, endpoints, secrets, and permission assignments. Those differences should be modeled through solutions, environment variables, connection references, and deployment controls rather than manual edits after publishing.
Permissions drift is a lifecycle problem. An agent that started with one connector can accumulate broad access as new experiments are added. Release reviews should compare the agent’s current capability surface with its documented job.
Audit who asked, what the agent chose, and which identity acted
For sensitive actions, logs should connect the end user, conversation or trigger, orchestration decision, selected tool, authentication mode, backend principal, and final result. Without that chain, investigators may know an action occurred but not whether it represented the user or a shared service identity.
The risk-management perspective from CISSP security and risk management is relevant: controls are valuable when they reduce exposure and create evidence that can be reviewed.
Microsoft’s current Copilot Studio identity model adds another reason to design this explicitly. New agents receive Microsoft Entra Agent IDs, while older agents may still use legacy app registrations. The platform can expose connector-related scopes on the agent identity, giving administrators a clearer inventory of what an agent is configured to call. That visibility is useful for governance reviews and for detecting capability creep over time.
Connector scope and resource permission are not identical concepts. An agent identity may show permission to execute connector operations, while the actual downstream access still depends on the connector’s authentication mode and service authorization. Security teams should trace the full path rather than assuming an Entra permission list alone describes every effective privilege.
Consent needs an owner. When users authenticate to a connector, they may grant access that follows their own account. When a maker supplies a shared connection, organizational approval should cover the service identity and its privileges. In both cases, teams should know how permissions are revoked when the agent is retired or the user changes role.
Secrets and credentials should stay in managed connection infrastructure, not in instructions, variables intended for conversation, or copied environment configuration. If a custom API requires credentials, use supported secret-management and connection patterns. Putting a key into an agent prompt creates a governance and leakage problem that no amount of behavioral instruction can solve.
Environment separation should include permission separation. A development agent should not use a production credential merely because it makes testing easier. Test systems should contain representative roles and data boundaries so authorization defects are found before deployment. Production access should be granted through the release process, not inherited accidentally from a developer’s personal connection.
Conditional Access and channel behavior also deserve review because identity enforcement can vary by how the agent is reached and which authentication flow a connector uses. Do not assume that a control tested in one channel automatically protects another. Validate the actual production channel, authentication mode, and downstream service path.
Finally, access reviews should remove permissions as well as add them. When a tool is deleted, a process changes, or an integration is replaced, confirm that obsolete connections and service privileges are revoked. Least privilege is not a one-time design state; it is a maintenance practice that keeps the agent’s authority aligned with its current job.
Privileged operations should use stronger review than ordinary reads. Creating a record and granting a role may both be “write” actions technically, but their risk is very different. Classify permissions by business impact so the agent’s approval and monitoring controls reflect consequence, not merely API method.
Break-glass access should stay outside normal agent behavior. Emergency administrator accounts and highly privileged recovery paths are designed for controlled human use, not routine orchestration. If an agent requires emergency-level authority to complete its normal job, the architecture has probably granted the wrong responsibility to the agent.
Permission decisions should be documented in business language as well as technical scopes. “Can call connector operation X” is useful to administrators, but reviewers also need to know that the operation means “read the signed-in user’s calendar” or “create a case in the shared support queue.” Mapping technical privilege to business effect makes access reviews more meaningful.
Security monitoring should look for anomalous patterns such as unusual action volume, repeated authorization failures, or a sudden increase in use of a sensitive tool. The agent layer creates a new interface to existing systems, so monitoring should confirm that usage remains consistent with the role the architecture intended.
Identity and permissions are therefore part of agent design from the first architecture sketch. Decide who the user is, who the agent is, whose credentials each tool uses, which operations are necessary, where authorization is enforced, and how that decision will be audited. A well-designed agent does not merely know what it should do. Its identity system makes it impossible—or at least substantially harder—to do what it should not.