Security

Security groups identity and evidence surfaces in tabs: SSO / IDP, Egress, Audit Logs, Data Export. The SSO / IDP tab connects single sign-on and directory sync through the secure setup portal instead of inline credential fields.

Two setup cards start the flow. Single sign-on (SSO) configures SAML or OIDC with the identity provider. Directory sync (SCIM) auto-provisions and deprovisions members from the directory. Each card opens its guided setup from the portal.

• Directory group to role mapping binds identity-provider groups to elevated roles, or ignores groups that should stay unbound.
• Unmapped groups are informational no-ops: directory users still receive the default standard role. Only an explicit mapping to a missing role counts as a warning.
• The observed-groups table shows each group with its state (Unmapped), a Map-to picker for granting an elevated role, and Ignore for keeping it silent.
• The remaining tabs (Egress, Audit Logs, Data Export) are product surface; treat the UI as the source of truth for what each holds.

Scope note: platform-level internals (identity provider wiring, provisioning flags) belong to Platform ops and are not documented here. If a control you expect is not visible in your tenant UI, ask the PRESHai team rather than assuming it exists.

Credentials and the vault

Agent credentials live in the Secrets vault: tenant secrets are referenced as grants, never pasted values, and platform-side signing material stays in managed secret storage. How those pieces fit together is Security architecture. The rule for everyone: no password, API key, token, connection string, or private key goes in chat, reasoning, code, tests, fixtures, or this wiki — names of variables where sources name them, values never.

Sign-in hygiene: checklist

• Every person uses their own named identity. No shared accounts, ever.
• Access changes on role change or departure go through offboarding promptly
• Invite links are shared directly with the intended person, not posted in group channels
• Anyone reporting sign-in trouble gets help quickly. Slow account recovery drives password-sharing workarounds.

Least privilege: checklist

• Admins at 3 or fewer with absence coverage (Roles)
• Operators earned solo approval rights by pairing first
• Members see only the environments their work needs
• Quarterly membership review is scheduled and happens

Session and approval hygiene: checklist

• Operators decide approvals at request time, not in batches
• Denials exist in the record (zero denials means rubber-stamping, so investigate)
• Sensitive departures trigger a review of recent sessions and approvals
• Session goals stay single and scoped; sprawling sessions get ended and restarted

What to watch

Signal	Meaning	Action
Approval with no clear what/on-what/why	Agent or environment issue	Deny; report with session reference
Risky work with no approval gates	Policy too loose	Stop, report to PRESHai team immediately
Routine work constantly gated	Policy too tight	Collect examples, request tuning
Unfamiliar identity in member list	Stale or wrong grant	Verify, remove if unneeded
User “cannot reach a system”	Connector not provisioned for the environment	Verify tool list; request provisioning. Code is not connected.

Incident posture

If you suspect misuse or a compromised identity:

1. Remove or demote the identity first. Contain, then investigate.
2. Preserve the record: note tenant hostname, org scope, session references, timestamps.
3. Contact the PRESHai team with that evidence pack.
4. Review and tighten: how did the access exist, and what prevents recurrence?

What next

• Security architecture: how client secrets stay protected end to end.
• Secrets: the vault agents draw credentials from.
• Roles: the role table this mapping grants into.
• People: the membership list this hygiene protects.