Juno runs inside your estate, signs people in through the identity provider you already use, and carries each person’s rights into every query, every answer and every agent run.
Five steps; the rights are part of the query, so they apply before a single row is read.
Access starts with your own directory. Juno signs people in through single sign-on, and reads the groups and roles the directory holds. A person who leaves the company loses access to Juno at the same moment as everywhere else.
A role carries two things: the screens and actions a person may open, and the data that person may read. The second part is the one that matters most for answers, because a question can reach several systems in one query.
Row and column rules travel with the query. Juno adds them while it writes the query, so the federated query engine reads the rows the person may read. The connection to each source applies its own rights on top, which gives two checks on the same request.
Where a role hides a column, the answer says so. ChatLima states which information is restricted and which role reads it, so a person knows a figure exists and who to ask. The secure answers page shows the same question answered for three roles.
Four groups of three: the session, the application, the data and query, and the infrastructure under them.
| Group | Layer | What it does | What your team sets |
|---|---|---|---|
| Session | Single sign-on | Signs people in through your identity provider. | The provider and the groups that map to roles |
| Session | Session control | Ends idle sessions and checks the device policy. | Time-outs and device rules |
| Session | Transport encryption | Encrypts traffic between every part of the platform. | Certificates from your own authority |
| Application | Role-based access | Carries what a person may open and read. | The roles, and the people in each |
| Application | Object permissions | Holds rights per project, catalogue, screen and agent. | Which teams own which objects |
| Application | Action limits | Checks value, daily budget, confidence and rate before an action. | The figure for each limit, per agent |
| Data and query | Row rules | Limits the rows a person or an agent reads. | The rule per role, such as plant or region |
| Data and query | Column rules | Limits the columns a person or an agent reads. | The fields each role reads, such as price |
| Data and query | Encryption at rest | Encrypts the platform database, the lake copy and files. | Your keys and your rotation period |
| Infrastructure | Network boundaries | Holds outbound traffic to the destinations on your list. | The destinations, including the model link |
| Infrastructure | Secrets in your key store | Keeps keys in your store and reads them at the moment of use. | The store, the paths and who may read them |
| Infrastructure | Audit logging | Records every access, question, action and export. | The retention period and where logs go |
Product. The platform runs on GCP, Azure, AWS or a private cloud, on an open-source core.
The rights decide the rows; the ontology keeps the meaning the same for everyone.
| Who asks | What the answer holds | What the answer states as restricted |
|---|---|---|
| J. Ridley · supply chain director | Every plant, with quantities, dates, suppliers and cover. | Contract prices, held for the finance role. |
| J. Harrison · finance lead | Values, prices and liability across every plant. | The complete answer for this question. |
| D. Okafor · buyer | The suppliers and plants inside their own scope. | Plants outside that scope, held for the plant owner. |
| A supplier partner | Their own orders, confirmations and delivery dates. | Other suppliers, held for your buyers. |
One question, asked in the same words, produces four answers. The difference comes from the rules attached to each role, applied while the query is written. The audit log holds one entry per question, with the person, the terms used, the systems read and the rights applied.
This is what lets a supplier portal, a plant team and a finance team share one set of definitions. The ontology gives everyone the same meaning, and the access rules give each person their own slice of the rows.
The agent is a user of your systems, so it holds an identity, a scope and limits like any other.
Forrester, August 2025, asks for “least agency”: the fewest capabilities, tools and permissions an agent needs to do its job. An agent in Juno is defined that way from the start, because its scope of data, its actions and its limits are fields on the agent, set by the person who owns it.
Gartner, 30 September 2025, found that 74% of application leaders regard agents as a new attack vector, and 13% strongly agree their governance is adequate. The answer on this page is ordinary security practice applied to a new kind of user.
SailPoint, 28 May 2025, surveyed 353 IT professionals: 82% already use agents, 44% have policies for them, and 80% had seen an agent take an action it was meant to leave alone. An identity per agent and a scope per agent are what make such an action visible and preventable.
Okta, 12 August 2025, reports that 10% of organisations have a developed strategy for identities that belong to software. Juno treats every agent as one of those identities, with the same joiner and leaver handling as a person.
Showcase estate.
L. Tan asked which open purchase order lines could still be cancelled that week and what they were worth. The answer covered both plants in scope, with quantities, dates and suppliers, and stated that contract prices were held for the finance role.
J. Harrison asked the same question an hour later and received the values, because the finance role reads price. A supplier partner asking about the same orders on the portal saw their own lines alone. All three questions sit in one audit log with the person, the ontology terms, the systems read, the rights applied and the query, and the PO cancellation agent that acted on those lines ran under its own identity, with read access to five tables and one write route to SAP S/4HANA.
Every run in full, the numbers a manager reads per 1,000 decisions, the cost per decision, and alerts on the agents themselves.
The difference is whether the rights are rebuilt or carried.
The common pattern is to copy data into a reporting tool or a model platform, and to rebuild the permissions there. Two sets of rules then exist for the same rows, and they move apart as roles change in the source system.
Juno reads the rows where they are, applies the asking person’s rights while the query is written, and keeps the connection’s own rights on top. One set of rules, checked twice, over data that stays in its source.
From the directory your organisation already runs. Juno maps its groups to roles, so joiners and leavers are handled once, in the place your IT team handles them today.
Yes. An agent runs under its own identity with its own scope of tables, fields and actions, and every read and write it makes is logged against that identity.
The answer states that the information is restricted and names the role that reads it. The person knows the figure exists and who to ask, and the request is logged.
In your source systems. The federated query engine reads them in place, and where a governed copy is needed for history, it lands in your own lake under the same rules.
Each one builds on the one before it.
Reads your rows in place.
Connect and move ↗One record per real thing.
Master and govern ↗Apps for every decision.
Operate and decide ↗Asks and acts, at your level.
Ask and act ↗Bring two systems and one decision your planners make every week. In the first week we register the data, confirm the mapping with your team, answer your questions in ChatLima and run the first agent at the level you choose.
