Skip to main content
Endor Labs built the Agents Hub so you can trust what an agent is and what it can do. Two properties support that. Endor Labs authors and signs the catalog, and every agent action carries the identity of the person the agent acts for and stays read-only.

​
A signed, Endor-authored catalog

Endor Labs authors the agents in the open source endorlabs/endor-labs-agent-kit repository and publishes them as a cryptographically signed release. Endor Labs verifies that signature against a pinned key before serving the catalog to your tenant. If verification fails, Endor Labs keeps serving the last known good catalog and never serves an unverified one. Because Endor Labs verifies the catalog on its side, the Agents Hub only ever shows you agents that came from the published, signed release. You can’t add a custom agent to the Agents Hub in this release, and no third party can inject one. See the safety model for how checksum verification protects an agent’s files after you install it.

​
Read-only by design

Agents reach Endor Labs data under a read-only credential. An agent can read findings, projects, and other resources, but it can’t change Endor Labs state. When an agent proposes a change, such as a dependency upgrade, it opens a pull request or merge request in your source control provider, and you review it there. The agent doesn’t write the change back to Endor Labs. This keeps you in control of anything that lands.

​
Attributed to a person

Endor Labs attributes every request an agent makes to the person the agent acts for, and groups every request made under the same delegated token into one session. A session lasts as long as the token, up to one hour. Endor Labs sets attribution when it issues the credential, from the identity that authenticated. An agent can’t assert that it’s acting for someone else. Attribution means you can tell, per agent and per session, whose access an agent used and what it read. See Agent activity for where this appears.