Every assistant gets the role the person already has, every scope is readable before approval, and nothing publishes until a person fires it.
You are being asked to approve a tool an LLM can drive. What decides your answer is what that assistant can read the moment someone connects it, and whose permissions it is reading with. The learning surface your people would otherwise reach ungoverned is role-scoped, admin-gated and logged.
Access over MCP is granted only to the data the person's Juno role already permits.
Connecting over MCP does not open up new categories of data.
Tools a person is not permitted to use do not appear to their assistant.
OpenAI, Datadog, SendGrid, Google Cloud and MongoDB are named on our Trust Center.
Our Trust Center publishes AI training data and bias, AI security, and employee AI usage.
An assistant can read within that role and prepare work. Firing it is covered under Approval below.
Every prompt we publish tells the assistant to ask first, preview, and wait for a person: read them all at /prompts.
The AI record on our Trust Center
Identity and access is the first section of your questionnaire and the fastest place to reject a vendor. Juno delegates sign-in, provisioning and deprovisioning to the directory you already operate. What follows is the posture; the setup fields live on the integrations page.
Okta, Microsoft Entra, Google, and any SAML 2.0 compliant provider.
Your HRIS or HCM syncs over SCIM, on a schedule, with sync logs.
Auto-provisioning is gated on the email domains you allow.
Remove someone in your directory and their Juno access goes with them.
Juno never sees or stores your users' passwords for any integrated service.
Entry point, certificate, issuer, callback URL and attribute mapping are on the integrations page.
A consent screen gets approved somewhere in your company every quarter, usually by someone who cannot read what it grants. Our own documentation publishes, for every integration, what it does, who consents, and the auth model. The negative half is published too, and that is the half nobody publishes.
Slack is requesting permissionJuno Journey
Requested by a workspace admin
This app will be able to
users:read, users:read.emailMatch Juno learners to their Slack accounts by email addressim:writeOpen a direct message conversation with a learnerchat:writeSend notification messageschat:write.publicPost shared content into public channels without being invited to each onechannels:read, groups:readList channels so admins can link a Juno channel to a Slack channelRevoking access
Remove the Juno app under Slack admin · Manage apps, or disconnect Slack in Juno's admin integration settings.
Juno requests only the scopes each feature needs, and optional features use separate, optional scopes.
OAuth tokens and API credentials are encrypted before storage and are never exposed to the browser or client apps.
Every integration can be disconnected from Juno or revoked from the provider's admin console, with revocation steps on each page.
Credentials and synced data are scoped to your organization and are never shared across Juno customers.
The consent screen names the requesting application, and the connection is revocable from the client that holds it.
Juno has no message-history scopes. It cannot read your workspace's messages, files, or conversations. It only sends.
Teams notifications request no Microsoft Graph API scopes and have no access to your tenant's data.
Juno does not read email, contacts, files, or the content of events it did not create.
A new platform usually arrives with a new set of administrators who can see everything inside it. Juno's roles are scoped by domain, so an administrator can be given one area and no others. What any of them does is on the record.
Roles scope to People, Content, Budget, Development, Engagement, Events, Channels, Company Automations and Platform.
Your effective access in a given area is the higher of your base role and your domain role for that area.
A blocked user can authenticate and sees no content.
Content Admin and Super Admin are documented roles, each bounded by the domains it holds.
View the system audit trail: who did what, when, filtered by action, user or date.
The row that did not exist two years ago is the one your board now asks about every quarter. Here is the mechanism, in the order it runs. An LLM connected to Juno reads inside one person's permissions and prepares the work; a person fires it, on a card that shows what is about to happen.
JunoAssign Refund policy 2026 to Support in Germany.
48 learners match, among them Dana Reuven, Tomás Beck and Wei Lin.
I'll assign "Refund policy 2026" to 48 people.
These 48 people will be enrolled and see it in their feed.
Every write action shows an approval card, and nothing is executed until you confirm.
The card shows the number of learners, a sample of names and any filters applied, and it is editable before you approve it.
All automations are created paused, with a one-click Enable so you can review the rule before it goes live.
A refused action returns a blocked card explaining what permission is needed.
Drafts stay invisible to learners until you publish them.
Publishing, assigning and notifying learners are named as high-impact actions to review before you confirm.
Our own documentation tells you to be mindful of prompt-injection risk when an assistant processes untrusted content.
Two pages next to this one, and one of them is about a different subject entirely.