The Engineering Intelligence System (EIS) Methodology is a documentation and process repository, not a production software package. Security concerns therefore fall into two categories: vulnerabilities in repository tooling or schemas, and unsafe use of the methodology in real engineering environments.

If you identify a security issue in repository tooling, examples, schemas, or automation added to this project, avoid publishing exploit details before the maintainer has had a reasonable opportunity to review the report.

Do not include credentials, private keys, access tokens, customer data, proprietary source code, or sensitive infrastructure details in public issues or pull requests.

EIS does not recommend giving AI unrestricted access to production systems.

Projects should explicitly govern capabilities such as:

• destructive shell commands;
• production database writes;
• secret management;
• access-control changes;
• deployment promotion;
• infrastructure mutation;
• public release or disclosure;
• irreversible data operations.

Where the consequence is material, inspection and mutation should be separated and explicit human authority should remain in the loop unless a separately reviewed automation policy already authorizes the operation.

AI tools and agents should receive only the permissions required for the contracted task.

Broad credentials such as unrestricted database access, organization-wide repository administration, or production root access should not be treated as convenience features.

Instructions to an AI model do not replace enforceable security controls.

Authorization, tenancy isolation, secret handling, network restrictions, database policy, protected branches, CI rules, and deployment controls should remain outside the model's discretion.

Evidence records may contain sensitive information. Projects adopting EIS should define retention, redaction, and access rules for:

• command output;
• logs;
• database queries;
• screenshots;
• traces;
• deployment metadata;
• user or tenant identifiers;
• test fixtures derived from production.

Evidence should be sufficient to support the engineering claim without becoming an unnecessary repository of sensitive data.

Adopting EIS does not certify a system as secure. The methodology provides a structure for controlling and verifying AI-assisted engineering work; security assurance still requires appropriate security engineering, threat modeling, review, and testing.