A connector is the integration path an agent uses to reach an external service, such as GitHub, Salesforce, or a custom API. Connectors matter because they expand the agent’s effective access scope and often determine the highest-risk permissions in the environment.
Expanded Definition
A connector is the integration path that lets an AI agent or automation reach an external system, usually through an API, webhook, or protocol adapter. In NHI security, the connector is not just plumbing; it is the control point that determines what the agent can do, where it can do it, and how much trust the target service must extend.
Definitions vary across vendors because some treat connectors as a product feature, while others treat them as an identity boundary or authorization broker. In practice, a connector often combines authentication, authorization, secret handling, request scope, and audit logging. That makes it closely related to NIST Cybersecurity Framework 2.0 concepts for access control and governance, even when no single standard governs connectors as a standalone category.
For NHI operators, the important question is not whether a connector exists, but whether its permissions are bounded, observable, and revocable. A connector with broad write access can become the highest-risk identity path in the stack, especially when an agent can invoke it autonomously. The most common misapplication is treating a connector as a harmless integration layer, which occurs when teams grant persistent broad scopes to speed up deployment.
Examples and Use Cases
Implementing connectors rigorously often introduces friction in onboarding and change management, requiring organisations to weigh agent productivity against tighter approval, scoping, and monitoring. That tradeoff is usually worth it when the connector can reach production systems or sensitive records.
- An AI agent uses a GitHub connector to open pull requests, but the connector is limited to a single repository and cannot merge code, preserving separation of duties.
- A Salesforce connector lets a support agent draft case updates, while approval gates prevent the agent from exporting customer data or modifying role assignments.
- A custom API connector to internal finance systems is wrapped with short-lived credentials and request-level logging so every action can be attributed back to the invoking NHI.
- A ticketing connector is allowed to read incident metadata but not close incidents automatically, reducing the chance of unsafe autonomous remediation.
- An MCP-based agent uses a connector to call external tools, but the token scope is narrowly constrained and rotated through the same lifecycle controls described in the Ultimate Guide to NHIs.
These examples show why connector design is often a governance decision first and a technical decision second. The same integration pattern can be low risk or high risk depending on scope, review cadence, and whether secrets are stored outside a managed control plane. Guidance in the NIST Cybersecurity Framework 2.0 is useful here because it ties access restrictions to measurable risk treatment rather than convenience.
Why It Matters in NHI Security
Connectors are where NHI exposure becomes operational. They concentrate privilege because a single integration may hold API keys, delegated OAuth grants, or service account access that reaches multiple downstream systems. NHI failures frequently begin with connector sprawl, over-scoped tokens, or unmanaged third-party access, and those conditions are reflected in the Ultimate Guide to NHIs, which notes that 97% of NHIs carry excessive privileges.
That statistic matters because connector risk is rarely about the connector alone. It is about the identity behind it, the secret that authenticates it, and the permissions inherited from the target service. When connectors are not reviewed alongside rotation, offboarding, and least privilege, they become durable attack paths that survive team turnover and application change. Mature programs treat connector inventory as part of NHI governance and align it with zero trust and continuous verification principles described in NIST Cybersecurity Framework 2.0.
Organisations typically encounter connector risk only after a token leak, privilege abuse event, or agent misfire, at which point connector scope becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Connectors often hinge on secret storage and overbroad access, a core NHI risk area. |
| NIST CSF 2.0 | PR.AC-4 | Connector permissions map directly to access control and least-privilege governance. |
| NIST Zero Trust (SP 800-207) | SC-7 | Connectors must enforce segmentation and continuous trust validation for agent access. |
Apply zero trust to connectors by limiting pathways, verifying every request, and logging usage.
