Harbor SDK
Tool Connectors That Never Show the Agent the Keys
The same credential problem, a different layer: what happens when the agent never touches the tool at all, only the connector does?
Yesterday I wrote about Infisical Agent Vault, a tool that solves credential exfiltration by intercepting network traffic and injecting secrets at the proxy layer. The agent never sees the key. The proxy does the substitution. If that architecture made sense to you, Harbor SDK is going to make you uncomfortable, because it takes the exact opposite approach to the same problem and does so with a conviction that deserves attention.
Harbor does not sit at the network layer. It sits at the tool layer. The distinction matters more than it sounds. Agent Vault solves credential exfiltration by making the agent send placeholder tokens through a proxy. Harbor solves it by making the agent invoke abstract tools through a connector, and the connector handles authentication, connection management, and schema negotiation on the agent’s behalf. The agent never opens a database connection. It never makes an HTTP request. It never learns a database schema or an API surface. It says “run this query” or “call this endpoint,” and the Harbor runtime executes the operation with credentials the agent cannot access because they live in a different process, in a different security context, on the other side of an API boundary.
If Agent Vault is a credential proxy, Harbor is a tool sandbox. The agent sends intents. The Harbor runtime resolves those intents against registered connectors, authenticates with the right credentials, and returns the results. The agent receives structured content blocks (text, JSON, skill bundles) but never the raw HTTP response, never the database cursor, never the API key header. The threat model shift is subtle but real. Agent Vault prevents the agent from knowing the credential. Harbor prevents the agent from knowing the tool even exists as a network primitive. The agent sees the tool as an abstract function in a registry. It has no information about how the function is implemented, what credentials it uses, or what infrastructure it connects to.
The Harbor SDK itself is a set of generated client libraries that connect to the Harbor runtime. Three packages: @hrbr/client for TypeScript hosts, @hrbr/sdk for system-level integrations, and harbor-sdk for Python. The surface is deliberately small. Create a client with a workspace ID and an API key, call runtime.execute with a code string or a tool invocation, get back typed content blocks. The client knows its own credentials, the workspace API key, but the agent does not receive that key. The client belongs to the application host, not to the agent. The agent runs inside the host’s runtime, which provisions the client, and the agent interacts with Harbor through tool abstractions that the host has registered. The security boundary is between the agent and the host, not between the agent and the network.
A concrete example helps. An agent in a customer support pipeline needs to look up order history from a PostgreSQL database and send a status update through a REST API. With Agent Vault, you would configure the proxy to intercept connections to the database and the REST endpoint, inject the appropriate credentials, and let the agent write SQL queries and HTTP requests directly. The credential is safe, but the agent still knows the database schema, still knows the REST endpoint URL, and still has the freedom to construct any query or request within the bounds of the proxy’s egress filter. With Harbor, you register two connectors: a PostgreSQL connector and a REST connector. The agent invokes harbor.runtime.execute with a tool name like “lookup_order” and a parameter like {"order_id": "..."}. The PostgreSQL connector translates that into a parameterized query using credentials stored in the Harbor workspace. The agent never writes SQL. It never constructs an HTTP request. It never sees a connection string or an API key. It selects from a menu of pre-registered tools, and each tool has a defined input schema and a defined output shape that the connector enforces.
This is a higher level of abstraction than a credential proxy, and it comes with a higher upfront cost: every tool the agent can use must be registered, implemented, tested, and maintained as a connector. Agent Vault’s onboarding is closer to “set the proxy and store the credential.” Harbor’s onboarding is closer to “write a connector for every integration and deploy a Harbor runtime.” For an agent that needs access to five APIs, that is five connectors to build. For an agent that needs access to a single internal API, the overhead of Harbor may exceed the security benefit. The tradeoff is unambiguous: Harbor trades development velocity for runtime isolation. The question is whether your threat model justifies that trade.
Harbor is also pre-release. The current PyPI package, harbor-sdk v0.2.0, was published in March 2026. The GitHub repository, at roughly 390 stars, distributes the npm packages as release artifacts rather than registry publishes. The README explicitly states that the npm and PyPI registry lanes have not been opened yet and lists them as roadmap items. The local development server works, the client libraries are functional, and the protocol surface is stable enough to generate Python and TypeScript clients from the same schema. The hosted control plane at tryharbor.ai provides workspace management, credential storage, and the full Harbor dashboard for teams that want the managed experience. The project is built by Zonko Team and carries a clear MIT license.
The architectural comparison between Harbor and Agent Vault is the kind of decision that forces a team to state what they actually believe about agent security. Agent Vault assumes the agent is competent but untrusted. It lets the agent do its job while ensuring the credentials cannot be exfiltrated. Harbor assumes the agent should not have direct access to anything. It wraps every external integration in a connector that mediates the interaction. The first model trusts the agent’s intent but not its security. The second model trusts neither. The decision between them reduces to a question about blast radius. If the worst thing a prompt-injected agent could do with direct tool access is read public data from a low-sensitivity endpoint, the connector model is overengineering. If the worst thing is modifying production database records with credentials that a connector could scope to read-only operations, the connector model is the only model that prevents that class of failure.
Both projects are early. Agent Vault at v0.39.0 with 1,900 stars has more production feedback and a broader agent integration list. Harbor at its current maturity has a cleaner abstraction at the cost of less real-world validation. The field is moving fast enough that neither should be viewed as settled. What should be settled, for any team deploying agents with tool access, is that the default pattern of hardcoding API keys in environment variables and hoping the agent uses them responsibly is not a security posture. It is a bet, and the bet is that prompt injection either will not happen to you or will not be sophisticated enough to extract credentials. Those are two separate assumptions, and both have to be right for the default pattern to hold. Agent Vault and Harbor are two different ways to stop making that bet. Which one you pick depends on whether you want to isolate credentials at the network layer or isolate tool access at the integration layer. Pick one. The default is not an option.
If this was useful, forward it to one engineer who needs less noise in their feed.