Acts as the person, with their own sign-in
A team works for the person who hired it, using that person’s delegated Microsoft sign-in. There is no shared super-account. Revoke it and the team stops.
Security and control
AI that works for your people without working around your rules
The question is not whether AI can use mail, chats and business systems. It is whether it can do so safely. NEGIN.SI is built so that access is explicit, limited, approved when it matters, and recorded.
Least privilege, per tool
Each tool declares exactly which permissions it needs and what kind of action it is: read, draft, final or external. A team gets those permissions and nothing more.
Approvals for what matters
Final or external actions can wait for a yes. People can allow a kind of action for good, and withdraw it at any time.
A record of every call
Every tool call passes one gateway that decides per call and keeps an audit log. Administrators can see what each team did and for whom.
Rehearse before it is real
A dry run reads real data but only describes what it would create, send or save. Nothing is changed.
Your infrastructure
Designed to run on your Kubernetes, with persistent volumes for the databases and secrets read from your own secret manager.
Untrusted text stays untrusted
Mail and chat messages are information, never instructions
AI that reads mail can be tricked by mail. Every team is told that text written by other people is data. The only voices that can change a team's rules are its owner, in the owner chat, and its saved notes.
- Hard stops. Money, contracts, legal, HR and outside parties always go to the owner.
- One owner per instance. Each person's team keeps its own notes, ledger and conversation, separate from everyone else's.
- Labelled output. Messages a team sends are marked as written by the team, so colleagues can tell.
Secrets never live in the platform's configuration
API keys, signing secrets and vault keys come from your secret provider at deploy time. Stored sign-ins are encrypted, and the key is held only by the execution engine.
Identity and roles
Single sign-on and role-based access
Staff sign in through your identity provider. Roles decide which pages and which actions each person can reach, and administrators can stop or restart any running team.
OIDC single sign-on
Works with your OpenID Connect provider, with roles carried in the sign-in.
Roles
Operators, designers, administrators and super-administrators see and change different things.
Usage you can see
Per-team and per-person token use, runs and status in the admin console.
Ask what a team could do, then watch it do it
Start in dry run or in watch mode. Move to acting when you are ready.