uplyst.Security and governance
Connected information must retain its ownership, permissions and meaning. Review those boundaries throughout the architecture.
Access
Who can access information and authorize actions?
Separate the source identity, derived information and authority to perform an action.
- Source permissions and service identities
- Policy decisions for queries and relationships
- Approval and authorization for workflow actions
Data lifecycle
Where does information go?
Follow source records, temporary processing and retained derivatives across the proposed architecture.
- Access paths, regions and ownership
- Caches, indexes, logs and derived records
- Retention, removal and downstream responsibilities
Recovery
What happens when something changes?
Review dependency failures, permission changes and incomplete information alongside the successful path.
- Traceable changes and access decisions
- Recovery procedures and incident ownership
- Required availability and contractual evidence
Security and governance requirements
Discuss your requirementsIdentity and authorization
Source access should be evaluated in the context of the identities, roles and policies that already govern enterprise information. A query, a graph relationship and a workflow action may each have different permission requirements.
Review least privilege, service identities and access controls against the policies in your environment. Source access, derived information and workflow actions need their own authorization decisions.
Data lifecycle
An evaluation should establish what information is accessed, where it is processed, what is retained and how it is removed. Consider derived data as well as source records: indexes, embeddings, cached queries, logs and screenshots can carry sensitive information.
Document residency constraints and ownership before introducing new data paths. Where an architecture uses access without wholesale replication, review the operational behavior of caches, temporary materialization and downstream processing explicitly.
Operational controls
Security and operations teams agree the evidence required for evaluation, including access decisions, change records, lineage, event traces and recovery procedures.
Discuss availability commitments, contractual terms, subprocessors and supporting assurance documentation with the team as part of your evaluation. Agree on the evidence needed to assess each requirement in the proposed architecture.
Security review
Share the policies, threat model and operational controls that a proposed architecture must satisfy. Review authentication, authorization, tenant boundaries, data quality and incident ownership as connected concerns.
The review should cover unavailable dependencies, changed permissions and incomplete information, including who investigates and how the service recovers.