AI agents carry out many types of work. Some answer questions from a knowledge base. Others retrieve information, draft workflow steps, or coordinate work across business systems. The security issue often appears in the path an agent can create across data, tools, and identities, not in any one permission alone.
Security teams need to know whether an agent's activity makes sense for the user, the agent, and the work at hand. That requires more than a static permission review and more than a generic anomaly detector. It requires a living profile of the user, a profile of the agent, and classification of the capabilities that connect them to data and systems.
Human access review already depends on context. A procurement analyst and an employee relations specialist may both be authenticated, but they do not normally need the same systems, data, or workflows. AI agents need the same treatment, whether they answer a question, retrieve data, draft a response, or execute a workflow.
A user profile should capture security-relevant context such as role, team, data domain, normal workflows, and the agents that the person is expected to use. An agent profile should capture its intended audience, business function, permitted topics, data sources, tools, authentication model, and level of autonomy. Both profiles should be purpose-bound and limited to what security needs to make a decision.
When those profiles are available, a reviewer can ask a sharper question than whether an activity was allowed: does this user interacting with this agent for this task fit the work the organization intended?
Agent behavior baselining is useful, but history alone is not an adequate starting point. An agent can be configured with excessive privileges on day one. If its early activity becomes the baseline, a poor design gradually looks normal.
Agent Intent supplies the reference point. It describes what an agent is meant to do before observed activity has a chance to redefine normal. A meeting assistant may reasonably use calendar context, summarize a transcript, and draft a follow-up. Broad repository access, external sending, or the ability to change account settings requires a separate, explicit justification.
Not every agent plans a multi-step workflow. Some simply formulate a response, while others retrieve information or invoke a tool under a user's direction. Security review should still capture the relevant sequence: the request, the data involved, the identity used, the capability selected, and the resulting outcome. As agents receive more autonomy, that sequence becomes longer, and the consequences of a mismatch grow.
Consider a service desk agent who normally summarizes inbound requests and drafts internal responses. A user-provided document leads it to open a credential-backed connector, retrieve restricted material, and send a result to an outside recipient. The user may be legitimate and the connector may be approved. The chain still deserves attention because the data, identity, destination, and action no longer match the agent's expected role.
Agent behavior is shaped well before runtime. System prompts define the primary task and constraints. Skills add reusable instructions and routines. Connectors determine which systems the agent can reach, how data moves, and which identity authorizes action. A Model Context Protocol (MCP) server can expose another set of tools and resources. These components are not implementation details when they alter what an agent can see, decide, or do.
An agent inventory cannot merely list those components. It needs to classify each MCP resource, MCP tool, or connector action by whether it can introduce untrusted content, reach outside the trusted environment, take a high-impact action, or use an identity with broader authority than the user who initiated the work.
These are posture attributes, not automatic verdicts on any individual capability. The risk is in the combination. A capability that reads untrusted external content needs different scrutiny when the same agent can delete records, send data outside the organization, or access sensitive knowledge. Changes to prompts, skills, connectors, MCP servers, sharing, and authentication should therefore be treated as profile changes.
A review loop can stay practical if it compares four things:
A security signal becomes stronger when the gap across those four views is clear, and the potential impact is material. An unexpected read might be a normal exception. An agent that can process untrusted input, perform a high-impact action, and reach beyond the trusted environment is a different class of posture risk. The same is true when sensitive knowledge, untrusted input, and external reach coexist.
The identity behind a capability deserves its own review. When an agent runs a tool with the builder or owner's credentials, people using the agent may be able to act with that person's authority or receive owner-level data. This can be a deliberate integration choice, but it should be explicit, narrowly scoped, and assessed alongside the agent's audience and sharing model.
With that context, AI Detection and Response (AIDR) can point to a real decision: validate a legitimate exception, narrow the agent's scope, restrict a capability, reduce credential reach, change the authentication model, or adjust how the agent is shared. The goal is to make agent activity intelligible enough to secure responsibly, whether the agent is assisted, supervised, or autonomous.
Agent behavior baselining is the practice of profiling how an AI agent normally operates across purpose, audience, tools, data access, identity use, workflow sequence, destinations, volume, and timing so meaningful deviations can be reviewed as security signals.
Runtime history can normalize an agent that was over-scoped from the beginning. Intent and approved configuration provide a cleaner reference point for judging whether observed behavior belongs.
It means using security-relevant context such as role, business function, expected data domains, and normal workflows to evaluate whether a user's interaction with an agent makes sense. It should be purpose-bound, reviewable, and proportionate.
Classify each capability by the type of input it can introduce, its data flow and external reach, whether it can modify or affect systems, the sensitivity of data it can access, and the identity that authorizes it. The classification should apply to the specific MCP resource, tool, or connector action, not only to the agent as a whole.
Risk rises when capabilities create a path from untrusted content to a high-impact action or an external destination. Sensitive knowledge or an overshared audience can raise the stakes further because they expand what the agent can expose or who can invoke it.
A tool that runs with the agent owner's credentials can apply the owner's permissions to work initiated by another user. That can expose owner-level data or allow actions that the interacting user could not otherwise perform, so the identity model must be part of agent posture review.
AI agents carry out many types of work. Some answer questions from a knowledge base. Others retrieve information, draft workflow steps, or coordinate work across business systems. The security issue often appears in the path an agent can create across data, tools, and identities, not in any one permission alone.
Security teams need to know whether an agent's activity makes sense for the user, the agent, and the work at hand. That requires more than a static permission review and more than a generic anomaly detector. It requires a living profile of the user, a profile of the agent, and classification of the capabilities that connect them to data and systems.
Human access review already depends on context. A procurement analyst and an employee relations specialist may both be authenticated, but they do not normally need the same systems, data, or workflows. AI agents need the same treatment, whether they answer a question, retrieve data, draft a response, or execute a workflow.
A user profile should capture security-relevant context such as role, team, data domain, normal workflows, and the agents that the person is expected to use. An agent profile should capture its intended audience, business function, permitted topics, data sources, tools, authentication model, and level of autonomy. Both profiles should be purpose-bound and limited to what security needs to make a decision.
When those profiles are available, a reviewer can ask a sharper question than whether an activity was allowed: does this user interacting with this agent for this task fit the work the organization intended?
Agent behavior baselining is useful, but history alone is not an adequate starting point. An agent can be configured with excessive privileges on day one. If its early activity becomes the baseline, a poor design gradually looks normal.
Agent Intent supplies the reference point. It describes what an agent is meant to do before observed activity has a chance to redefine normal. A meeting assistant may reasonably use calendar context, summarize a transcript, and draft a follow-up. Broad repository access, external sending, or the ability to change account settings requires a separate, explicit justification.
Not every agent plans a multi-step workflow. Some simply formulate a response, while others retrieve information or invoke a tool under a user's direction. Security review should still capture the relevant sequence: the request, the data involved, the identity used, the capability selected, and the resulting outcome. As agents receive more autonomy, that sequence becomes longer, and the consequences of a mismatch grow.
Consider a service desk agent who normally summarizes inbound requests and drafts internal responses. A user-provided document leads it to open a credential-backed connector, retrieve restricted material, and send a result to an outside recipient. The user may be legitimate and the connector may be approved. The chain still deserves attention because the data, identity, destination, and action no longer match the agent's expected role.
Agent behavior is shaped well before runtime. System prompts define the primary task and constraints. Skills add reusable instructions and routines. Connectors determine which systems the agent can reach, how data moves, and which identity authorizes action. A Model Context Protocol (MCP) server can expose another set of tools and resources. These components are not implementation details when they alter what an agent can see, decide, or do.
An agent inventory cannot merely list those components. It needs to classify each MCP resource, MCP tool, or connector action by whether it can introduce untrusted content, reach outside the trusted environment, take a high-impact action, or use an identity with broader authority than the user who initiated the work.
These are posture attributes, not automatic verdicts on any individual capability. The risk is in the combination. A capability that reads untrusted external content needs different scrutiny when the same agent can delete records, send data outside the organization, or access sensitive knowledge. Changes to prompts, skills, connectors, MCP servers, sharing, and authentication should therefore be treated as profile changes.
A review loop can stay practical if it compares four things:
A security signal becomes stronger when the gap across those four views is clear, and the potential impact is material. An unexpected read might be a normal exception. An agent that can process untrusted input, perform a high-impact action, and reach beyond the trusted environment is a different class of posture risk. The same is true when sensitive knowledge, untrusted input, and external reach coexist.
The identity behind a capability deserves its own review. When an agent runs a tool with the builder or owner's credentials, people using the agent may be able to act with that person's authority or receive owner-level data. This can be a deliberate integration choice, but it should be explicit, narrowly scoped, and assessed alongside the agent's audience and sharing model.
With that context, AI Detection and Response (AIDR) can point to a real decision: validate a legitimate exception, narrow the agent's scope, restrict a capability, reduce credential reach, change the authentication model, or adjust how the agent is shared. The goal is to make agent activity intelligible enough to secure responsibly, whether the agent is assisted, supervised, or autonomous.
