Hyundai Onboarding Pipeline
Overview
End-to-end automation of Hyundai's employee onboarding flow, built at Way-V. Every new hire generates a burst of sensitive data — full name, national ID (CPF), personal documents, banking details — that must land in multiple internal systems (HR, payroll, access management) before day one. Part of that flow was manual: PII copied between spreadsheets, forms, and systems. A security problem wearing an efficiency costume. THREAT MODEL FIRST — Before writing integration code, the question was: how does this pipeline fail, and what does it expose when it does? The controls weren't a compliance checklist bolted on at the end — they were the architecture. THE CONTROLS — All external input treated as hostile: schema validation, type checking, and sanitization at the edge before anything touches business logic. Documents in private S3 buckets with encryption at rest, accessed through a service-specific least-privilege IAM role — never user-bound credentials. Data minimization per integration: each destination system receives only the fields it actually needs, so a system that needs name and employee ID never sees CPF or banking data. Integrations exclusively through authenticated APIs with defined contracts — never direct database access. Secrets injected via environment configuration, never in code or Git history. PII-masked structured logging: full operational traceability without the logs becoming a shadow database of personal data. Generic external errors (internal detail goes to internal logs — error messages are free reconnaissance otherwise). Idempotent critical operations, because retries are not optional and a duplicated employee record is a second, unmanaged copy of someone's PII. RESULTS — Onboarding went from a multi-day manual process to an automated, consistent, traceable pipeline. PII stopped circulating through spreadsheets, intermediate copies dropped sharply, and each system's access shrank to exactly what its function required. Zero data exposure incidents across the period I operated it.
Links
Implementation
// production excerpt# Every external input is hostile until proven otherwise.
import structlog, boto3
from pydantic import BaseModel, field_validator
log = structlog.get_logger()
sts = boto3.client("sts")
class NewHire(BaseModel):
"""Edge schema — validation runs BEFORE anything touches business logic."""
full_name: str
cpf: str # Brazilian national ID — never logged in clear
bank_account: str
@field_validator("cpf")
@classmethod
def valid_cpf(cls, v: str) -> str:
if not _cpf_check_digits(v):
raise ValueError("invalid_cpf") # generic — no reconnaissance leak
return v
def _mask(cpf: str) -> str:
return f"***.***.***-{cpf[-2:]}" # PII-masked structured logging
def onboard(raw: dict) -> None:
hire = NewHire.model_validate(raw) # rejects malformed input at the edge
log.info("onboarding.start", cpf=_mask(hire.cpf))
# Service-specific, least-privilege role — short-lived, never user-bound creds.
creds = sts.assume_role(
RoleArn="arn:aws:iam::****:role/onboarding-writer",
RoleSessionName="onboarding",
DurationSeconds=900, # auto-expiring session
)["Credentials"]
# Data minimization: payroll gets name + employee_id, never CPF or banking.
payroll.push(name=hire.full_name, employee_id=_derive_id(hire), creds=creds)Validate at the edge, assume a short-lived least-privilege role, mask PII in logs.