AI Agent Posture Management: Who Built What, and What It Reaches

Security teams did not create an agent inventory problem. Business teams did, at speed, with tools that made it easy. Platforms like Microsoft Copilot Studio, Salesforce Agentforce, and n8n allow non-technical users to build and deploy agents in hours. No change ticket. No security review. No record in any system the security team controls.

The result is shadow AI at the agent layer. Not just shadow AI apps that receive data passively, but shadow agents that take autonomous actions, hold embedded credentials, and connect to production SaaS systems. An agent is not a browser tab. It is a machine identity with a blast radius.

Traditional security tools were not designed for this. Network and endpoint solutions cannot see agent activity across SaaS platforms. Identity providers track human logins, not agent invocations. Native platform logs exist but are siloed per tenant, require manual correlation, and do not answer the question security teams actually need answered: what can this agent actually do?

That gap is where AI agent posture management begins. Before any runtime enforcement conversation is possible, security teams need a complete, accurate picture of what agents exist, who owns them, and how they are configured. You cannot govern what you cannot see.

Agent posture management is one input to AI security posture management, the broader practice of governing the security state of AI systems across an environment. Posture answers how an agent is built and configured. AI-SPM covers that, plus the identity it acts through, the applications it can reach, and what it does at runtime.

1. Who built this agent, and does anyone own it?

Ownership is the foundational fact, and it is the one most environments cannot supply. Without a known creator, an agent cannot be scoped correctly, because nobody can say what the workflow needs, and cannot be retired safely, because nobody can say what breaks. Ownership gaps are also what produce orphaned agents that survive their creator's departure.

2. How is it configured?

What platform it runs on, what instructions it operates under, whether it runs on a schedule or on demand, whether a human reviews its actions, and how it connects to other systems. Connection type matters more than most of the rest: some platforms let an agent use its builder's credentials for every user rather than the invoking user's identity, which means everyone who uses that agent operates at the builder's permission level.

3. What can it actually reach?

Not what its configuration declares. What its credential reaches inside the connected system today. These two answers drift apart continuously, because scopes accumulate, roles nest, and integrations carry inherited access, while configuration is written once. This is the distinction between theoretical configuration and effective authority, and it is where nearly all real posture risk sits.

4. What else can it reach at the same time?

The most important question and the one asked least. An agent's authority is the union of everything available to it in a session, including every MCP server and integration attached over time by different people for different tasks. Nobody re-evaluates the total.

Across enterprise AI agent deployments, several configuration patterns consistently produce elevated risk. Understanding the mechanism behind each one is essential for prioritizing remediation.

Maker Mode with Sensitive Data Access

Maker mode is the default configuration in many agent builder platforms. When an agent is built in maker mode, it uses the creator's credentials for every action it takes, regardless of who invokes it. A user with no Salesforce access can invoke a maker-mode agent built by a Salesforce administrator. That user now has effective access to CRM data at the administrator's privilege level. No IAM rule was violated. The agent performed exactly as designed. Your access controls were bypassed.

This is the machine insider risk pattern. The agent acts like an insider with elevated credentials, but no insider risk program covers it.

• What the control enforces: maker mode detection flags every agent where the creator's credential level exceeds the invoker's provisioned access, surfacing the privilege gap before it is exploited.
• Why theoretical configuration fails: no configuration file reveals that a "read" connector resolves to admin-level authority inside the connected SaaS application after OAuth grant resolution.

Publicly Accessible Agents

An agent configured for public access can be invoked by anyone with its URL, including unauthenticated external users. This configuration is sometimes intentional for customer-facing use cases. It is frequently unintentional for internal workflow agents that were published without scoping the invocation audience. Posture management surfaces every publicly accessible agent and flags the combination of public access with sensitive data connections as a critical-priority finding.

• What the control enforces: invocation scope review ensures every public agent has a documented business justification and limited data access.
• Why theoretical configuration fails: public agents are often created as internal prototypes and never re-scoped, meaning the publicly accessible configuration persists long after the original use case changes.

Org-Wide Accessible Agents with Broad Permissions

An agent accessible to every user in the organization is not inherently dangerous. An agent accessible to every user in the organization while holding admin-level credentials to a financial system is a different matter entirely. Posture management identifies this combination and scores it accordingly.

• What the control enforces: combined scoring of access scope and permission level, not individual factors in isolation.
• Why theoretical configuration fails: org-wide accessibility and admin-level credentials each score as medium severity independently, masking the critical blast radius of their combination.

Hardcoded Credentials

Some agent configurations embed credentials directly in workflow definitions or connection strings. These credentials do not rotate. They do not expire. If the agent configuration is exported, shared, or accessed by an unauthorized party, those credentials travel with it. Platforms like n8n and others that support workflow-based agent building are particularly susceptible to this pattern.

• What the control enforces: credential hygiene scanning across all agent configurations, flagging any embedded credential not routed through a secrets management system.
• Why theoretical configuration fails: hardcoded credentials appear legitimate in configuration reviews because the agent is technically authorized. The risk is in the credential's exposure surface, not its validity.

Agents with Disabled Owners

An agent whose creator account has been disabled continues operating with that creator's permissions. This is the orphaned agent problem. The human identity no longer exists in the IAM system, but the agent's effective authority remains intact. Posture management surfaces every agent where the creator account is disabled, treating these as high-priority findings regardless of the agent's other configuration signals.

• What the control enforces: real-time correlation between agent creator accounts and identity provider status, flagging every agent where the owner account has been deprovisioned.
• Why theoretical configuration fails: configuration reviews show the agent as "active" and credentials as "valid." The orphaned status is only visible when creator identity is correlated against a live identity provider.

Reporting risk factors individually produces a long list that nobody can act on. The signal is in the pairings.

An agent that can read sensitive data and send data outward has an exfiltration path. Neither capability is remarkable alone. Together they are a route from a customer database to an external destination through two entirely legitimate calls.

An agent with broad invocation rights and inherited privileged access is an access-broadening intermediary, letting anyone who can prompt it operate at a permission level they were never granted.

An agent with irreversible action capability and no human review and an unknown owner is the configuration behind most agent incidents worth writing up.

Ranking by combination rather than by individual finding is what makes posture output short enough to act on. Most agents have a few unremarkable properties. A small number have properties that stack, and those are the list worth working.

Posture is necessary and it is not sufficient, and being honest about the boundary matters.

Posture tells you an agent could read the customer database and could post to an external channel. It does not tell you whether it did, whether the combination was ever exercised, or whether the sequence that just executed was the benign one or the other one.

Configuration also cannot resolve intent. An agent with broad access performing its normal job looks identical, in configuration terms, to the same agent being prompted by someone using it as an access intermediary. Only the actual behavior separates them.

So posture establishes the boundary of what is possible, and narrows it by removing capability that is not needed. Runtime observation covers what actually happens inside that boundary, and enforcement stops specific actions in the execution path. Posture makes the runtime problem smaller. It does not replace it.

Obsidian covers both halves: an inventory of agents across connected AI platforms with the creator behind each one, the effective access each holds inside your SaaS applications resolved from runtime activity rather than configuration, and scoring on the combinations that widen blast radius. Runtime enforcement is available today for Claude and Microsoft Copilot; other platforms are covered for discovery and governance.

For how agent posture fits the wider category, and the questions that separate AI-SPM platforms, see AI-SPM: value, best practices, and evaluation.