Access & Security Policy

1. Separate authorization is required

Payment, an NDA, repository ownership, or access credentials do not by themselves authorize every test or change. Before access is used, the written scope must identify the systems, environments, accounts, activities, and responsible client contact. The client must be entitled to grant that permission.

AppGrout will not intentionally access systems or data outside the agreed boundary. If a test unexpectedly exposes another tenant, customer, system, or secret, work on that path stops while the parties agree safe next steps.

2. Access principles

• Use named, individual accounts rather than shared identities.
• Grant the minimum role, repository, environment, and duration needed.
• Prefer staging, test projects, synthetic data, and redacted evidence.
• Keep production write access disabled unless the scope expressly requires it.
• Use the client’s existing audit logs and branch-protection controls where available.
• Revoke access promptly at handover or earlier on request.

3. Repository and code access

Repository access should use an invitation to a named account with access limited to the agreed repository. For review-only work, read-only access is preferred. Repair work should use a dedicated branch or fork and a reviewable pull request unless another method is agreed. AppGrout does not merge or deploy changes without the authorization stated in the scope.

Do not email source archives or upload them to the AppGrout portal. If a temporary working copy is necessary, it is stored only in the approved work environment and handled under the engagement’s retention terms.

4. Credentials and secrets

Never submit passwords, API keys, private keys, recovery codes, database exports, or production tokens through the public inquiry, checkout, or intake fields. Prefer temporary accounts, scoped tokens, test credentials, and a client-approved secret-sharing channel.

AppGrout will not ask for a personal password when a role invitation or scoped credential is available. Secrets exposed during review are treated as findings; the client remains responsible for rotation unless rotation is expressly included in the scope.

5. Production systems and customer data

Production access is exceptional. Any approved production activity must identify the exact action, expected impact, maintenance window if needed, backup or rollback path, and person authorized to approve or stop the work. Destructive tests, uncontrolled writes, bulk data changes, denial-of-service tests, and access to unrelated customer records are excluded by default.

Clients should provide synthetic, masked, or minimized data. If regulated or identifiable customer information is necessary, the parties must first agree data-processing terms, allowed fields, location, access, and deletion requirements.

6. Tools, AI services, and additional reviewers

Local and automated tools may support an engagement, but findings and recommendations are reviewed by a person. AppGrout may use AI services whose applicable business or API privacy terms state that customer data is not used to train shared models. We submit only what is reasonably needed and exclude credentials and unnecessary personal data.

Team members or contractors may receive private access only when needed for the accepted scope. They must be bound by confidentiality and least-privilege requirements. Stricter signed Client terms still apply.

7. Changes, verification, and rollback

• Define acceptance criteria before implementation starts.
• Keep changes isolated and reviewable where the repository supports it.
• Run targeted checks for the agreed flow and record meaningful limitations.
• Do not describe an untested environment or flow as verified.
• Require explicit approval before a production deployment or data migration.
• Record the deployed version and post-deployment verification when deployment is in scope.

8. Security events

If AppGrout becomes aware of unauthorized access, disclosure, or a material security event involving client material, we will notify the designated client contact without undue delay, share the known relevant facts, take reasonable containment steps, and cooperate with the agreed response. A contract or applicable law may require a specific notification period.

9. Handover and removal

At engagement closure, AppGrout and the client should record:

• the delivered report, branch, pull request, or other agreed artifacts;
• open findings, untested areas, and any client-owned follow-up;
• repository, cloud, database, payment, monitoring, and communication access revoked;
• temporary credentials rotated or disabled;
• working copies and evidence scheduled for deletion; and
• any restricted records retained under the contract or law.

10. Reporting a concern

Report a suspected access or security issue to admin@cendra.co. Describe the affected project and how we can contact you, but do not include additional credentials or sensitive evidence in the initial message.