What we read
- Connected app names, scopes, and installation metadata
- Machine identity and bot inventory data
- Credential age, rotation timing, and ownership metadata
- Risk posture signals used to produce scan results and evidence
Product Architecture
How Loqet Shield works
This page is for technical buyers who want to understand the operating model before trusting a new security product with workspace access. The design goal is simple: read only what is needed to build a non-human identity inventory, risk it accurately, and surface evidence without introducing a heavy deployment model.
Your tools
Slack, GitHub, and other systems provide inventory metadata through OAuth connections.
OAuth connection
Read-only access is used to enumerate apps, scopes, identities, and credential posture.
Loqet scan engine
The engine builds an identity graph, normalizes findings, and maps ownership gaps.
Risk analysis
Findings are scored for severity, credential age, and remediation priority.
Dashboard
Security teams review risks, generate evidence, and guide remediation from one workspace view.
What data we read, and what we never touch
The security model should be understandable. The product is meant to reduce uncertainty, not add another black box to your environment.
What we never access
- Message bodies or direct message content as part of the core scan flow
- Source code repositories cloned into Loqet infrastructure by default
- Raw secrets stored as a long-term credential vault
- Infrastructure agents or code changes installed into your environment
Integration directory
Current coverage is centered on the places where non-human identity risk accumulates first. Additional integrations should expand the same operating model rather than invent a separate one.
Live
Slack
App inventory, bot visibility, OAuth scope review, and workspace risk analysis.
Live
GitHub
Automation identities, repository-linked credentials, and workflow-related exposure signals.
Coming soon
Google Workspace
Service account inventory and app access posture for workspace-connected systems.
Coming soon
AWS
IAM role and machine identity posture designed for cloud-side NHI governance.
Technical specs
OAuth mode
Read-only for initial discovery and inventory workflows
Core scan target
Apps, bots, service credentials, machine identities, and posture metadata
Default scan time
About 90 seconds for first-pass discovery
Stored data
Scan results, identity metadata, and evidence-oriented posture summaries
Retention model
Operational scan results kept for history, auditing, and comparison views
Continuous monitoring
Available on paid plans through scheduled scans and notifications
Compliance posture
SOC 2 support
In progressThe product generates evidence aligned to access-control conversations, but formal certification claims should remain conservative until completed.
Security review posture
OperationalThe product is designed around read-only initial access, explicit remediation actions, and limited data retention for scan workflows.
Audit transparency
Available nowTeams can review what was scanned, when it was scanned, and which controls or findings were derived from that run.
Data retention policy
Loqet Shield should behave like an operational security product, not like a system that hoards more information than it needs. The retained layer is centered on scan history, risk comparison, and audit support.
Instant scan results
Kept so teams can compare posture over time and revisit prior findings.
Credential posture summaries
Retained as part of scan history rather than as a secret-management database.
Evidence artifacts
Stored long enough to support ongoing audits and compliance workflows.
Connection data
Maintained while the workspace remains connected and the customer account remains active.
Operational model
Built for fast evaluation, explicit access, and auditable change.
The guiding principle is that technical buyers should understand what is connected, what is being read, and what state is being preserved before the product ever becomes part of a security workflow.