> For the complete documentation index, see [llms.txt](https://docs.keeper.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.keeper.io/keeperpam/ai-and-developer-tools/overview.md). # Overview

Keeper Secrets Manager is built for CI/CD, DevOps, SDKs, Ansible, Terraform, and third-party integrations. It gives enterprises one place to govern secret access through **Devices** and **Applications**. Features like **Universal Secrets Sync** extend that access to cloud secret stores and shared workflows. **Local development** needs a different model. Developers need secrets in local builds, tools, and AI workflows without copying values into files, terminals, or chat. **Keeper AI and Developer Tools** bring that control to the workstation. This page introduces three core capabilities: * [**Property File**](#property-file-record-type) records for local secret delivery * **AI and Developer** tools in Keeper Desktop * [**MCP access**](#mcp-for-ai-agents) for local AI agents with approval controls ### Property File Record Type **Property File** is a new vault record type for developer and agent workflows. It controls how vault data is exposed to local tools and AI agents.

A Property File stores any number of name/value pairs. You can mount the record as a virtual file on the local machine by clicking **Add Destination**. The file exists at the chosen path, but its contents stay protected until a process requests access.

Property Files behave like other vault records. You can share them with users and teams. You can also use them with Keeper Secrets Manager workflows, CI/CD pipelines, and infrastructure automation. They also work for a single developer on a local workstation.

Developers can point local software or an AI agent to the mounted destination file. When a process requests access, Keeper prompts the user to approve or deny the request. Approval can be granted once or reused for future requests, similar to the Keeper SSH Agent workflow.

### Developer Benefits Property Files improve local development without weakening secret controls. * Secrets stay encrypted in the Keeper Vault instead of being copied into local files * Approved local tools always read the latest record values * Developers can switch between environments by changing which Property File they reference * Teams can share the same workflow across local development, CI/CD, and Keeper Secrets Manager integrations ### AI and Developer The **AI and Developer** tab gives developers one place to manage local integrations, agent access, and Property File workflows. It is the main entry point for setting up secure developer tooling in Keeper Desktop. On the tab, developers can create Property File record types, set up AI integrations, SSH agent, CLI tools and all of the advanced 3rd party tool integrations.

### MCP for AI Agents The **AI Agent Access** section lets developers enable the local MCP service in Keeper Desktop. This allows approved AI agents to interact with Keeper through a controlled interface.

#### Available tools When MCP is enabled, connected AI agents can use the tools you allow: * Create and manage Property File Records * Read secrets * Create secrets * Share a record * Share a folder * Launch PAM sessions and tunnels * Request access to a PAM resource * Perform remote command execution with PAM Machines * Perform remote database queries with PAM Databases

Users can approve or deny requests from local AI agents. They can also review connected agents and revoke access at any time from the **AI Access** screen.

### Interaction with PAM Resources When PAM tools are enabled in **AI Access**, approved AI agents can interact with PAM resources managed through the Keeper Gateway and routed through Keeper Desktop. #### PAM Machine connections To allow an AI agent to interact with a managed [PAM Machine](/keeperpam/privileged-access-manager/getting-started/pam-resources/pam-machine.md): * Edit the PAM Machine record in the vault * Open **PAM Settings** * Go to the **MCP Access** tab and allow access * Optionally add **AI Context** to guide the agent before it runs commands on the target system

Example of MCP Access to a remote machine

#### PAM Database connections To allow an AI agent to interact with a managed [PAM Database](/keeperpam/privileged-access-manager/getting-started/pam-resources/pam-database.md): * Edit the PAM Database record in the vault * Open **PAM Settings** * Go to the **MCP Access** tab and allow access * Optionally add **AI Context** to guide the agent before it runs queries against the target database In the example below, the context explains how to calculate ARR so the agent can query the data correctly.

Example of MCP Access to a remote database

### Role enforcement and reporting Keeper administrators can restrict **AI Agent Access** for users through **Roles → Enforcement Policies → AI Agent Access**. Admins can disable the feature entirely or limit which MCP tools are available.

The **AI Governance** tab provides reporting across the user base, including MCP access and tool usage.

### Commander CLI Integration Keeper Commander CLI now ships with Keeper Desktop. Developers can authenticate through the desktop app without separate device registration or local configuration. Authentication flows directly between Commander CLI and Keeper Desktop. Learn more in [Commander Overview](/keeperpam/commander-cli/overview.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.keeper.io/keeperpam/ai-and-developer-tools/overview.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.