Module 10 — Build and Extend · Lesson 10.3
Apps and the Marketplace
Installing community apps, approving their scopes, and the switch that lets the agent use them
~10 min
What you'll learn
- Browse and install an app, reviewing its scopes
- Manage or uninstall from the Installed tab
- Turn on community app tools for the agent, and explain why it is off by default
- Evaluate an app before installing it
An app is a way for someone outside Kavanah to add capability to your workspace — new agent tools, new integrations. That is powerful and it is a supply-chain decision, so the install flow makes you approve what it wants and the agent access is a separate, explicit switch.
Discover, Installed, Build
Apps sits under the Build group and has three tabs.
Discover is the marketplace: browse what is available.
Installed manages what you have. Each installed app has its own agent-access switch, so you can install something for its surfaces without exposing its tools to the agent.
Build is the route to publishing your own, via the Developer console. That is the next lesson.
Installing and the scope approval
Pick an app and review the scopes it requests before installing. You approve them at install time.
This is the moment that matters, and it deserves the same attention as an OAuth consent screen — more, arguably, because an app is code someone else wrote running against your workspace.
Read what it asks for against what it claims to do. An app that formats reports and requests membership access is asking for something it does not need, and that mismatch is the signal worth acting on.
After install, the app's surfaces become available and — subject to the switches below — its tools become available to the agent.
The two switches
There are two levels of control over whether the agent can use app tools, and both must be on.
Workspace level: 'Community app tools' under Settings → AI Agent, admin only, off by default. Until this is on, no installed app can reach the model at all.
Per app: each installed app has its own agent-access switch on the Installed tab.
This two-level shape is deliberate. The workspace switch is a policy decision — does this organization let third-party code drive its agent? The per-app switch is an operational one — does this particular app, which we have installed, get that access?
And note that app tools are governed like any other tool. An app tool that writes to an external system is an external write and follows the same action policy. Installing an app does not create a path around governance.
Evaluating an app
Four questions before installing.
What does it need to reach, and does that match what it does? Scope mismatch is the clearest warning sign available.
Where does its tool endpoint run? An app's tools are hosted on the developer's server, which means using it involves sending data there. That is fine for many apps and unacceptable for some data.
What happens if it goes away? An app you have built a workflow around is a dependency on someone else's continued interest.
And could you do this without it? Often the answer is yes with a bit of the agent and an automation, and the maintenance-free version is worth more than the polished one.
Install one deliberately
- 1
Apps under Build. See what exists before deciding whether you need anything.
- 2
Read the scopes against what the app claims to do
A mismatch between what it asks for and what it does is the clearest warning available.
- 3
Turn on community app tools if you want agent access
Settings → AI Agent, admin only, off by default. Until it is on, no installed app reaches the model.
- 4
Use the per-app switch for granular control
Installed tab. Install for its surfaces without exposing its tools, if that is what you want.
What to watch
- Installed-but-unused apps
- Apps installed with no activity in the last month.
- Healthy signal: None. An unused app is a standing grant and a dependency with no benefit.
- Scope breadth per app
- How much each installed app is allowed to reach.
- Healthy signal: Matched to function. Anything asking for more than its job needs deserves a second look.
Key takeaways
- ·Three tabs: Discover to browse, Installed to manage, Build to publish your own.
- ·You approve the app's scopes at install — treat it like an OAuth consent screen, or more carefully.
- ·Two switches gate agent access: the workspace-level community-app-tools setting, and a per-app switch.
- ·App tools are governed by the same action policy as everything else; installing is not a way around it.
- ·An app's tools run on the developer's server, so using one means sending data there.
Next: the other side of that marketplace — building and publishing an app of your own.