Employee access policy.

We don't ask you to trust our employees. We built a system where trusting them is unnecessary.

“No Nayker employee can access, read, copy, or decrypt any customer vault content. This is not a policy decision — it is an architectural constraint.”

Zero human access to customer vault

No Nayker employee has credentials, SSH keys, or console access to production vault storage. Not engineering. Not operations. Not executives.

Only automated IAM role touches KMS

A single, purpose-scoped IAM role is authorized to call AWS KMS. This role is assumed only by the vault service at runtime — never by a human principal.

Every KMS call is CloudTrail logged

All KMS API calls are logged to an immutable CloudTrail trail in a separate AWS account. Logs cannot be deleted or modified by the production account.

Manual access attempt → immediate alert

Any attempt to assume the vault IAM role from a human session, or any sts:AssumeRole call outside the expected service, triggers an immediate PagerDuty alert and auto-revokes the session.

Vault IAM Policy (simplified)

vault-iam-policy.json

{
  "Effect": "Deny",
  "Principal": {
    "AWS": "arn:aws:iam::root"
  },
  "Action": [
    "kms:*"
  ],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:PrincipalArn":
        "arn:aws:iam::role/NaykerVaultService"
    }
  }
}

This policy ensures only the NaykerVaultService role can access KMS. All human principals — including root — are explicitly denied.