Kiteworks Agent Marketplace Gives Your AI Assistant Governed Access to Regulated Data
Many regulated organisations have already rolled out an AI assistant. The harder part is pointing it at the data that matters: contracts, case files, invoices, board papers and technical records. The Kiteworks Agent Marketplace exists to close that gap without creating a second, ungoverned copy of the data.
Security and governance teams usually face two bad options. They can block the assistant from sensitive repositories, and the investment under-delivers. Or they can look the other way while people download, paste and screenshot, which moves regulated data outside every control and audit trail the organisation built.
This article explains why blocking backfires, how governed agents run inside Kiteworks as the requesting user, and how to start with one low-risk folder rather than a platform project.
Executive Summary
An AI assistant that can’t reach sensitive data produces workarounds, and workarounds are unlogged data movement. The Kiteworks Agent Marketplace is a public catalog of more than 70 governed agents that run on Kiteworks MCP, so the assistant reaches data through the same permissions, policies and audit trail as every other data exchange. For security, compliance and IT leaders, the outcome is useful AI against sensitive data, a smaller attack surface than ad hoc exports, and an audit trail that now covers the AI agent channel as well as email and file sharing.
Key Takeaways
- Blocking the assistant relocates AI risk instead of reducing it. When sanctioned tools can’t reach sensitive data, people move the data to the tool, and that movement leaves no audit trail.
- Governed agents run as the requesting user. An agent inherits the user’s roles and permissions, so it can’t see or do more than the person asking it.
- Policy is evaluated on every request. Attribute-based policies weigh classification, user attributes and context in real time, which keeps access decisions with the platform rather than with the assistant.
- Security tokens never enter the assistant’s context. In local mode, the data in transferred files stays out of it too unless the user reads a file in on purpose, which answers the prompt-injection question directly.
- Start with one low-risk folder and a read-only pilot. Enabling the connector is an administrative action, so you can prove the control model before you widen access.
Why Blocking the Assistant From Regulated Data Backfires
Blocking feels like the safe answer. It isn’t, because the demand doesn’t disappear. People still need to summarise a contract, find a clause or compare two versions, and the assistant is the fastest route. If the sanctioned route is closed, they open another one.
What People Do Instead
They download the file, paste the text into a prompt or take a screenshot. Each of those actions is the same data exchange as before, minus identity checks, permissions and logging. A security team can’t review what it never saw, and an auditor can’t sample an event that left no record.
Why a Policy Document Doesn’t Close the Gap
An acceptable-use policy tells people what to do. It doesn’t give them a governed way to do it. The organisation needs a path where the assistant reaches sensitive data under the same controls as every other channel, so that saying yes to AI doesn’t mean saying no to oversight.
How the Kiteworks Agent Marketplace Brings Governed Agents Into Your Assistant
The Kiteworks Agent Marketplace is a public catalog of governed agents for your AI assistant. Every agent runs on Kiteworks MCP, which means the work happens inside Kiteworks rather than in a copy of your data somewhere else. Claude is supported today across the web app, Desktop and Claude Code. The catalog is browsable before anyone speaks to a vendor, and each agent declares its tool scope up front.
Agents Act as the Requesting User
An agent doesn’t get a privileged identity of its own. AI operations inherit the authenticated user’s roles and permissions, and attribute-based policies evaluate file classification, sensitivity labels, user attributes and context for every request. The access surface doesn’t grow, and there’s no new privileged identity to govern.
What Stays Outside the Assistant’s Context
Security tokens are never made available in the assistant’s context. In local mode, files move on a separate data channel, so their data stays out of the context unless the user explicitly reads a small text file in. The connector enforces this, not the assistant’s good behaviour. It matters for prompt-injection reviews, where the question is what a manipulated assistant could reach.
Starting With One Low-Risk Folder
Enabling the marketplace is an administrative setting, not a migration. Administrators switch on MCP in the Kiteworks admin interface, which uses a single built-in OAuth application they manage there. After that, people add the connector once, either for the whole marketplace or a single agent, and the built-in capabilities need nothing installed at all.
What a First Pilot Should Prove
Pick a folder that matters but isn’t your most sensitive, and run read-only tasks first. Check three things: whether the agent saw only what the user could see, whether each call appears in the audit log with the right user attribution, and whether your policy blocked what it should have blocked. If all three hold, widen the scope with evidence rather than optimism.
Governing the AI Agent Channel on the Kiteworks Data Control Plane
Posture tools show where sensitive data lives, and IAM decides who may sign in. DLP inspects what leaves. None of them governs the moment an AI agent acts on regulated data on someone’s behalf. That’s the role of the Kiteworks Data Control Plane. The Agent Marketplace extends it into the assistant, so agent calls follow the same identity, permissions and data-aware policy as email, file sharing and APIs, and land in a tamper-proof audit log that can feed your SIEM tooling.
It complements your existing DSPM, IAM and DLP investments rather than replacing them. To see which agents fit your first pilot, browse the catalog, or schedule a custom demo and bring the one workflow your assistant can’t reach today.
Frequently Asked Questions
Blocking feels safe but fails because demand persists; users then download files, paste text, or take screenshots, moving data outside identity checks, permissions, and logging with no audit trail for security teams or auditors to review.
Agents run on Kiteworks MCP inside the platform rather than on external data copies. They inherit the requesting user’s roles and permissions, with attribute-based policies evaluating classification, sensitivity, user attributes, and context on every request; security tokens never enter the assistant’s context.
Select a low-risk folder and run read-only tasks to verify that the agent accesses only what the user can see, each call appears in the audit log with correct user attribution, and policies block unauthorized actions before widening scope.
It extends existing controls so agent calls follow the same identity, permissions, and data-aware policies as email or file sharing, landing in a tamper-proof audit log that feeds SIEM tools while complementing DSPM, IAM, and DLP investments.