Security & Trust
Questions or security reports: [email protected].
What Enji Guard Can Access
Enji Guard can access only the data and systems needed for the actions you enable:
- account and product settings;
- selected projects, repositories, and websites;
- GitHub App installation and repository metadata;
- task, schedule, and report metadata;
- generated reports, artifacts, issues, pull requests, and summaries;
- feedback messages and screenshots you submit.
Repository and website access is tied to user-selected actions and verified GitHub App access.
The Execution Layer
Enji Guard is the product interface. The Enji Fleet agents orchestrator is the execution layer behind it.
The Enji Fleet agents orchestrator handles agent execution, tasks, schedules, runbooks, artifacts, authentication, and permissions. Enji Guard stores the product-layer records needed to make those workflows easier to use.
If Enji Guard product-layer state and Enji Fleet agents orchestrator execution state disagree, the orchestrator-owned execution state should be treated as the source of truth.
Repository Access
Repository access is provided through the Enji Guard GitHub App.
The GitHub App is installed by the user in GitHub. Enji Guard verifies access to selected repositories before repository-backed tasks run. Access can be revoked in GitHub.
Enji Guard should not rely on durable GitHub installation ids as the security boundary. Repository access should be verified through the Enji Fleet agents orchestrator before tasks use the repository.
More detail is available in GitHub App Permissions.
Authentication And Access
Authentication is handled by the Enji Fleet agents orchestrator. The current product flow supports Google OAuth and access-code gating.
Enji Guard verifies orchestrator-issued user identity before serving product API routes. Pending users should not be able to mutate product data until they complete the access flow.
Product Demo/Pro mode is an Enji Guard product mode. It is not a replacement for orchestrator-owned authentication or permission checks.
Agent Runtime
The Enji Fleet agents orchestrator runs agent tasks in controlled execution environments. Agents receive the task context needed for the selected action, such as repository context, website targets, runbook instructions, and output language.
Repository-backed tasks run in isolated containers. After execution, the containers are shut down and removed together with the cloned repository code. Enji Guard and the Enji Fleet agents orchestrator do not retain full repository clones after task completion.
Agents may produce reports, artifacts, GitHub issues, and pull requests. Users must review agent output before accepting it.
AI Model Providers
Enji Guard does not train or operate its own foundation models.
The Enji Fleet agents orchestrator uses approved third-party AI model providers and coding tool providers under the providers’ public data-use and retention terms unless a separate written agreement says otherwise.
More detail is available in AI Data Use.
Secrets And Logs
Enji Guard and the Enji Fleet agents orchestrator should avoid logging secrets, cookies, raw authorization headers, model-provider credentials, GitHub tokens, or customer secrets.
Where implemented, log masking and redaction should be enabled by default. Customers should still avoid intentionally placing secrets into support messages, feedback screenshots, task descriptions, or public summaries.
Human Access
Support engineers do not inspect repository code for ordinary support requests. They may review service logs and operational metadata when a customer asks for help with a failed or unexpected run.
Security access is different. If Enji.ai detects or reasonably suspects a security incident, abuse, malicious prompt injection, harmful agent instruction, or attempted misuse of Enji Guard or the Enji Fleet agents orchestrator, authorized security personnel may investigate relevant repository content, generated artifacts, task inputs, logs, and related records. Enji.ai may escalate serious incidents to law-enforcement or regulatory authorities when required or appropriate.
Public Summaries
Executive summaries are private by default and require authorization inside Enji Guard.
They become publicly accessible or indexable only when the owner explicitly chooses to publish them after seeing a warning. A public/indexable summary can be viewed by anonymous visitors and may be indexed by search engines until the owner makes it private, revokes access, or deletes it where supported.
Do not publish or index a summary that contains confidential information unless you are comfortable sharing it outside your organization.
Security Headers And Browser Protection
The production web server should use security headers such as Content Security Policy, HSTS where appropriate, frame protection, content-type protection, and strict referrer policy.
Do not make public SOC 2, ISO, penetration-test, or compliance claims until the corresponding audit or certification exists.
Incident Contact
Report suspected vulnerabilities, account compromise, data exposure, or security incidents to [email protected].