An employee builds an agent to answer questions about supplier contracts. They connect a document library, add an email tool, and share it with colleagues. The platform is approved. The employee has legitimate access. The agent solves a real problem.
But whose permissions does it use when a colleague asks a question? Can it return contract terms that colleague should not see? And does an agent built to answer questions need permission to send those terms outside the company?
These are the questions AI governance and security need to answer as agents gain access to enterprise data and autonomous authority to act.
AI governance and security combine the policies, accountability, and technical controls organizations use to manage AI responsibly and protect their data and operations. Governance establishes who is responsible, which uses are acceptable, and what oversight is required. Security identifies exposure, detects harmful activity, and applies controls.
For AI agents, this means understanding who created each agent, what it is intended to do, whose permissions it uses, what it can access, and whether its actions remain appropriate.
Broader AI governance also addresses areas such as fairness, transparency, and model quality. This article focuses on governing and securing employee-built agents across enterprise AI platforms.
Approving an AI platform then rolling it out to the enterprise workforce is one decision. Determining whether every agent built inside LLMs like Copilot, Enterprise GPT, and Claude has appropriate access is an ongoing responsibility.
Employees can create agents without following the same development and review process used for traditional software. In our State of Agentic Adoption 2026, Opsin's research arm, Opsin Labs, analyzed production environments across eight enterprise verticals between March 2025 and June 2026. Among its findings:
These findings illustrate two practical challenges: the bulk of agent creation extends to departments beyond engineering, and access can persist after accountability disappears. An intake form can record what someone intended to build. It cannot, by itself, establish whether the agent still has the same owner, tools, sharing settings, or purpose months later. AI agent governance needs a continuing connection between the approval and the system operating in production.
An agent may retrieve documents, invoke tools, or perform actions using a human’s delegated permissions or another credential. Governing it requires tracking both the agent itself and the authority behind its actions.
Consider the supplier-contract agent. Its creator can read confidential agreements. Another employee can use the agent but does not have the same document access. If the agent operates through its creator’s credentials, that combination may create an unintended route to restricted information.
The relevant questions are specific:
Tracking these relationships makes least privilege actionable: the agent should have the access needed for its task, with a defined owner and a way to remove unnecessary authority.
A context graph connects people, agents, models, tools, and data sources so security teams can evaluate their relationships together.
The same document access can mean different things in different workflows. A finance agent retrieving payment terms for an authorized Finance employee may be expected. Returning the full contract to an unrelated department, or attaching it to an external email, warrants a different assessment.
The decision depends on the requester, the identity used, the sensitivity of the information, the intended task, and the destination.
Behavior adds another layer. A new tool call might be a legitimate workflow change. A sequence that collects sensitive records and sends them externally may carry much greater risk. Unusual activity deserves investigation, but unusual does not automatically mean malicious.
Context helps teams explain why an action is risky and choose a proportionate response. It also gives them a stronger basis for tuning alerts than keywords or isolated events alone.
Connect to supported AI platforms and cloud applications to identify agents and their configurations. Record a stable agent identifier, creator, accountable owner, deployment status, and available activity signals.
API-based discovery can reduce onboarding friction by collecting information through platform integrations. Coverage and depth depend on the APIs and connector permissions available. Include draft, inactive, and orphaned agents in the review. Lack of recent activity does not establish that an agent’s credentials or connections have been removed.
Determine who each agent is meant to serve, what information it needs, and which actions its task requires. Compare that purpose with its actual tools, permissions, audience, and data connections. For example, an agent intended to summarize supplier terms may need read access to selected contracts. Permission to change records or email arbitrary recipients requires a separate justification.
Opsin’s Agent Intent capability evaluates declared configuration, including instructions, tools, and provisioner identity, to identify potential misalignment before execution. Inferred intent should remain reviewable: incomplete instructions can leave uncertainty about what the builder intended.
Review permissions and tool configuration alongside available activity. Use controlled testing, including automated red-teaming where appropriate, to check whether an apparent exposure can produce a harmful result.
For the contract agent, test whether a user outside the intended audience can obtain restricted terms. Check whether a stated approval requirement is enforced by the connected system. Reassess when owners, instructions, tools, permissions, or sharing settings change. Historical behavior can inform a baseline, but normal past activity does not prove that excessive access is safe.
Choose the response based on the exposure. That may mean narrowing a document permission, removing an unnecessary tool, restricting an agent’s audience, revoking credentials, or quarantining an agent where supported.
Integrate these actions with existing identity, data protection, ticketing, and security workflows. A finding should identify the responsible owner, the recommended change, and how resolution will be verified.
Start with visibility and review, then introduce notifications and approvals for higher-impact actions. Automate responses when the risk conditions and consequences are sufficiently understood.
For example, an externally directed action involving restricted data may justify an approval gate. Disabling an agent used by an entire business unit calls for a clear understanding of operational impact and recovery.
Measure alert quality, remediation time, and disruption to legitimate work. Effective enforcement depends on accurate decisions and controls the underlying platform can actually execute.
Opsin’s approach brings agent identity, purpose, permissions, data access, tools, and activity into a shared context. This helps security teams understand what an agent can do, assess whether that reach fits its job, and prioritize issues for remediation. The need for that context appears in Opsin’s analysis of enterprise customer agent activity:
93% of misaligned tools connected to agents had full, unrestricted access to their connected systems.
Opsin uses API-first connections to supported enterprise AI platforms to support discovery, classification, risk assessment, and remediation workflows. Available visibility and corrective actions depend on the integration and its permissions. The roadmap extends toward runtime blocking and automated guardian remediation as enforcement capabilities develop.
As agents take on more responsibility, governance must follow the relationships between them: who delegated the work, which authority traveled with it, what information was shared, and whether the next action still serves the original purpose.
The goal is to give enterprises a defensible basis for deciding which autonomous work can proceed, which needs review, and which requires intervention.
AI governance defines responsibility, acceptable use, oversight, and decision-making for AI systems. AI security applies technical controls to protect those systems, their data, and the operations they can affect. For enterprise agents, the two work together to connect policy with permissions, monitoring, and corrective action.
Platform approval does not establish that every agent has appropriate permissions, tools, or sharing settings. Employees can configure agents for different purposes and audiences within the same platform. Governance evaluates those individual configurations and continues as ownership, access, and behavior change.
An AI agent inventory should include each agent’s identifier, creator, accountable owner, intended purpose, audience, credentials, permissions, connected data, tools, and available activity. It should also flag missing ownership and inactive agents that retain access, so security teams can prioritize review and remediation.
A context graph links agents to people, identities, models, tools, and data. These relationships help security teams assess whether an action fits the agent’s purpose, who requested it, and what information is involved. The context supports more precise prioritization and response than evaluating an isolated tool call alone.
Begin with discovery, ownership, and risk assessment. Validate findings, apply targeted permission changes, and add approval requirements for higher-impact actions. Expand automation as detection quality and operational consequences become clear, using supported platform controls and recovery procedures to limit disruption.
An employee builds an agent to answer questions about supplier contracts. They connect a document library, add an email tool, and share it with colleagues. The platform is approved. The employee has legitimate access. The agent solves a real problem.
But whose permissions does it use when a colleague asks a question? Can it return contract terms that colleague should not see? And does an agent built to answer questions need permission to send those terms outside the company?
These are the questions AI governance and security need to answer as agents gain access to enterprise data and autonomous authority to act.
AI governance and security combine the policies, accountability, and technical controls organizations use to manage AI responsibly and protect their data and operations. Governance establishes who is responsible, which uses are acceptable, and what oversight is required. Security identifies exposure, detects harmful activity, and applies controls.
For AI agents, this means understanding who created each agent, what it is intended to do, whose permissions it uses, what it can access, and whether its actions remain appropriate.
Broader AI governance also addresses areas such as fairness, transparency, and model quality. This article focuses on governing and securing employee-built agents across enterprise AI platforms.
Approving an AI platform then rolling it out to the enterprise workforce is one decision. Determining whether every agent built inside LLMs like Copilot, Enterprise GPT, and Claude has appropriate access is an ongoing responsibility.
Employees can create agents without following the same development and review process used for traditional software. In our State of Agentic Adoption 2026, Opsin's research arm, Opsin Labs, analyzed production environments across eight enterprise verticals between March 2025 and June 2026. Among its findings:
These findings illustrate two practical challenges: the bulk of agent creation extends to departments beyond engineering, and access can persist after accountability disappears. An intake form can record what someone intended to build. It cannot, by itself, establish whether the agent still has the same owner, tools, sharing settings, or purpose months later. AI agent governance needs a continuing connection between the approval and the system operating in production.
An agent may retrieve documents, invoke tools, or perform actions using a human’s delegated permissions or another credential. Governing it requires tracking both the agent itself and the authority behind its actions.
Consider the supplier-contract agent. Its creator can read confidential agreements. Another employee can use the agent but does not have the same document access. If the agent operates through its creator’s credentials, that combination may create an unintended route to restricted information.
The relevant questions are specific:
Tracking these relationships makes least privilege actionable: the agent should have the access needed for its task, with a defined owner and a way to remove unnecessary authority.
A context graph connects people, agents, models, tools, and data sources so security teams can evaluate their relationships together.
The same document access can mean different things in different workflows. A finance agent retrieving payment terms for an authorized Finance employee may be expected. Returning the full contract to an unrelated department, or attaching it to an external email, warrants a different assessment.
The decision depends on the requester, the identity used, the sensitivity of the information, the intended task, and the destination.
Behavior adds another layer. A new tool call might be a legitimate workflow change. A sequence that collects sensitive records and sends them externally may carry much greater risk. Unusual activity deserves investigation, but unusual does not automatically mean malicious.
Context helps teams explain why an action is risky and choose a proportionate response. It also gives them a stronger basis for tuning alerts than keywords or isolated events alone.
Connect to supported AI platforms and cloud applications to identify agents and their configurations. Record a stable agent identifier, creator, accountable owner, deployment status, and available activity signals.
API-based discovery can reduce onboarding friction by collecting information through platform integrations. Coverage and depth depend on the APIs and connector permissions available. Include draft, inactive, and orphaned agents in the review. Lack of recent activity does not establish that an agent’s credentials or connections have been removed.
Determine who each agent is meant to serve, what information it needs, and which actions its task requires. Compare that purpose with its actual tools, permissions, audience, and data connections. For example, an agent intended to summarize supplier terms may need read access to selected contracts. Permission to change records or email arbitrary recipients requires a separate justification.
Opsin’s Agent Intent capability evaluates declared configuration, including instructions, tools, and provisioner identity, to identify potential misalignment before execution. Inferred intent should remain reviewable: incomplete instructions can leave uncertainty about what the builder intended.
Review permissions and tool configuration alongside available activity. Use controlled testing, including automated red-teaming where appropriate, to check whether an apparent exposure can produce a harmful result.
For the contract agent, test whether a user outside the intended audience can obtain restricted terms. Check whether a stated approval requirement is enforced by the connected system. Reassess when owners, instructions, tools, permissions, or sharing settings change. Historical behavior can inform a baseline, but normal past activity does not prove that excessive access is safe.
Choose the response based on the exposure. That may mean narrowing a document permission, removing an unnecessary tool, restricting an agent’s audience, revoking credentials, or quarantining an agent where supported.
Integrate these actions with existing identity, data protection, ticketing, and security workflows. A finding should identify the responsible owner, the recommended change, and how resolution will be verified.
Start with visibility and review, then introduce notifications and approvals for higher-impact actions. Automate responses when the risk conditions and consequences are sufficiently understood.
For example, an externally directed action involving restricted data may justify an approval gate. Disabling an agent used by an entire business unit calls for a clear understanding of operational impact and recovery.
Measure alert quality, remediation time, and disruption to legitimate work. Effective enforcement depends on accurate decisions and controls the underlying platform can actually execute.
Opsin’s approach brings agent identity, purpose, permissions, data access, tools, and activity into a shared context. This helps security teams understand what an agent can do, assess whether that reach fits its job, and prioritize issues for remediation. The need for that context appears in Opsin’s analysis of enterprise customer agent activity:
93% of misaligned tools connected to agents had full, unrestricted access to their connected systems.
Opsin uses API-first connections to supported enterprise AI platforms to support discovery, classification, risk assessment, and remediation workflows. Available visibility and corrective actions depend on the integration and its permissions. The roadmap extends toward runtime blocking and automated guardian remediation as enforcement capabilities develop.
As agents take on more responsibility, governance must follow the relationships between them: who delegated the work, which authority traveled with it, what information was shared, and whether the next action still serves the original purpose.
The goal is to give enterprises a defensible basis for deciding which autonomous work can proceed, which needs review, and which requires intervention.
